Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

Fatal Errors (memory related)

Go to End

5 Posts   1721 Views


Community Member, 3 Posts

29 January 2008 at 7:44am

Edited: 29/01/2008 8:44am

SS Dev Team,

First off, I gotta say this is a pretty sweet script. I've played with quite a few CMSs, and I love the simplicity of management and integration that SS provides.

That being said, I just tried installing 2.2.1 on my live platform (Apache 2.2.6 [Unix], PHP 5.2.5, MySQL 5.0.45-community-log, shared-hosting at today, and encountered the 'Allowed memory' fatal error before it even finished installing. I had to increase the memory limit to 96M ( trying other values in the 60's and 80's before doing so ) to get the install, and the subsequent flush, to complete successfully. And even after that, a vanilla install wont run without the limit set >= 48M . I've searched the forums, seen that others are having the same issues, and noted the suggested work-arounds. They've worked for me (generally).

But guys, really. It isn't reasonable for a script to require so much memory. Especially for shared-hosting environments, like my live environment. They frown severely upon memory hogs. Joomla? Drupal? Never had issues with them, running under the default 32M. And they can get rather complex in terms of functionality... A little too complex, in fact. Joomla/Mambo expecially. Too much of a learning curve for non-savvy end-users like the people I'm developing for.

SS seems to be the best option for my needs... and I'd readily embrace it if it weren't for show-stopper issues like the memory issues. How does SS differ from CMSs such as Joomla or Drupal, that it requires so much memory? What tactics do they employ to manage memory demand, that SS does not? I'd pitch in and help optimize if I had the necessary PHP skills, which unfortunately I do not at the moment... but for right now, I'd at least like to understand whats different, hear the explanation for such a high requirement, and perhaps hear what steps are being taken to minimize the demand on memory (and when we can expect them implemented).

Thanks for your time, and an otherwise pretty darn awesome project!



Community Member, 470 Posts

29 January 2008 at 9:04am

I agree with you. I only found this project last week, and have already spent many hours reading/learning about it all.

I think this project has so much potential based on it's power and flexibility, and because the admin UI is brilliant. I've never come across a CMS that has such a good back end interface. It's absolutely perfect for my clients with no knowledge of web design.

However, I haven't converted yet because I am very worried about the memory issues. I host a lot of my clients on my own server, not shared, and the rest have shared hosting. I'm worried in both cases that as the sites grow, it'll break based on memory usage. I've read numerous tickets over on Trac, and in the forums about all the issues.

I've spent hours reading over everything and keep trying to convince myself to use this anyway, and that the issues will be fine and fixed, but I'm not sure I can do it just yet. I think I may have to wait for this project to develop further, because at the moment there are a lot of glaring issues with the code.

I don't mean any disrespect to the developers at all. I love this project, and the concept behind it, I just don't think it's stable enough just yet.


Community Member, 791 Posts

29 January 2008 at 10:00am

Edited: 29/01/2008 10:02am

I disagree with the statement that Silverstripe isn't stable. It has proven to be production ready (just look at the showcases and Silverstripe's (the company) own client projects).

There is, however, plenty of room for optimization of the codebase (both speed- and memorywise). The memory-issue for example keeps popping up on the forum. I don't feel this is an architectural flaw in the system but something which can be smoothed out over the next versions.

You cannot compare the underlying structure of a CMS like Mambo / Joomla with Silverstripe. Correctly implementing a 3 tier MVC framework always takes its toll on performance , be it in PHP , Java or whatever other language.


Community Member, 3 Posts

29 January 2008 at 11:25am

Thanks for the reply Fuzz :-).

What do you mean by 3tier MVC? AFAIK, each is its own concept, and they differ topologically... why is it that the MVC framework demands more resources? It seems to be that bypassing the controller would actually be more efficient in some cases.

I wouldn't necessarily call SS 'unstable'... But the memory issues do make adoption impractical for many shared-hosting users. Its not just a nuisance for those of us who don't have dedicated space... its a show-stopper. It is stated Here that the focus has been more towards features... which is great... except for the lower 50% of the potential userbase who can't actually use the script because of memory issues.

*shrugs* I mean no disrespect at all to the developers or their hard work. This has the makings of a really great CMS... it IS a great CMS. Its just not accessible to us in its current state. Efficient and accessible should always be high priorities, at least in my mind.



Community Member, 791 Posts

29 January 2008 at 11:43am

Hi ,

You are right on the terms.... My bad... Never new there was a difference.. ;)

> why is it that the MVC framework demands more resources

There is a lot of stuff that gets (automagically) done (handling requests , reading config-files / gathering files , executing (sub)-controllers , creating & passing (data)-objects) etc. etc. This all takes time.