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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

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

SilverStripe performance issues

Go to End

19 Posts   9289 Views


Community Member, 5 Posts

23 July 2009 at 8:21am

While working in my company with SilverStripe (versions 2.3.0 and 2.3.1) we faced serious performance issues. I would like to share our experience and ask if anyone else was having problems with SilverStripe's performance.

We've used SilverStripe for some websites before. Problem became visible when we created more complex one. Once few users started using it load on the server went up dramatically. At first we thought that it's because of this specific website but tests shown that all SS applications are affected. It's just not so visible in case of non popular websites. But still... couple of concurrent users is a rather poor performance. We've tested various types of websites from simple two-level menu structure to 4-5 levels deep. For some of simple websites 3 users effected in 3 points of server load. Complex website made load to go even above 70 (seven-zero). I have to mention that this server is running many PHP based websites and usually it's load doesn't go above 0.5.

Note: Other PHP applications installed on that server (mainly symfony based) don't share such behavior so it's SilverStripe related thing.

We tried to turn off some of the SilverStripe features (such as template rendering) to define what causes the issues. In each case load slightly decreased but it was still above accepted level. It looks like all SilverStripe parts give some overhead which all together causes load issues. So it's not a bug in any specific place in code but general problem in Sapphire framework architecture.

Only sensible solution was using static publisher. It works quite well but it's not applicable for all the pages. i.e. pages which require authorization cannot be cached. Since some websites have many of them the performance problem remains. Besides while using static publisher you cannot use menu control (<% control Menu %>) as mentioned in the discussion:

Tests where made on few different servers with different configurations. We've been using xcache 1.2.2, php 5.2.8 and php 5.2.4, apache 1.3.41 and apache 2.2.9. We've even tested it using nginx which didn't improve the situation too much.


Forum Moderator, 5523 Posts

23 July 2009 at 2:51pm

Edited: 02/08/2009 1:11pm

SilverStripe has a huge performance overhead. Delivering static files takes alot of the load off but we still constantly hit this performance barrier. We (the core devs) know about these performance issues but no magic bullet. Trunk does have some performance improvements to extensions but this is likely to be an on going battle.


Community Member, 127 Posts

23 July 2009 at 3:16pm

Hmmm that is a problem, which should be addressed with high priority.

Kuba, did you use silvertripe's caching, such as creating a silverstripe-cache folder, and if yes, did that make a difference?


Community Member, 5 Posts

23 July 2009 at 4:22pm

> Kuba, did you use silvertripe's caching, such as creating a silverstripe-cache folder, and if yes, did that make a difference?

Yes, we're using it from the very beginning and the problem is still there.


Community Member, 145 Posts

24 July 2009 at 4:24pm

Willr, if this is an issue with Silverstripe, how were you guys able to handle the US democratic website, with the amount of hits it was recieving? Did you just throw server hardware at it?


Forum Moderator, 5523 Posts

24 July 2009 at 4:38pm

Edited: 02/08/2009 1:26pm

DNCC did have a complex setup using MediaTemples Grid Server. The site was served nearly completely statically over the grid so we never swamped the server with MySQL or Apache process's instead most of the time it was just serving up html pages and videos were streaming straight off so we encountered quite little load.


Community Member, 712 Posts

24 July 2009 at 6:35pm

The first thing that should be done is to introduce autoloading instead of including everything in ManifestBuilder::include_manifest(). spl_autoloading is pretty well established and works great with Doctrine, for example.

Shouldn't be that difficult really, but I'm not familiar with what else ManifestBuilder does. It seems to me though that most of it's functionality can be replaced by Reflection methods.


Administrator, 690 Posts

31 July 2009 at 3:04pm

Hi Hamish,

We already do use autoloading; the thing that manifestbuilder includes is just an array listing the locations of all the files.

We're focusing on improving the performance of the underlying framework in 2.4.0, which should help with these issues. Because theese performance fixes will be relatively deep changes, there's not a lot we can do in the 2.3.x line.

Go to Top