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: http://www.silverstripe.org/customising-the-cms/show/263809?start=0.

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.

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.

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?

> 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.

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?

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 blip.tv so we encountered quite little load.

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.

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.