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've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

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   10730 Views

Avatar
Hamish

Community Member, 712 Posts

31 July 2009 at 4:48pm

Heh, yeah I went hunting for it and realised that it was handled in Core.php

Why not bundle it into ManifestBuilder as a static method?

Avatar
DasJacko

Community Member, 4 Posts

2 August 2009 at 9:25am

Have you guys thought about building out a memcache-d requirement and using memcache to store that huge manifest of file names/positions and info?

J.

Avatar
kuba

Community Member, 5 Posts

2 August 2009 at 6:27pm

> Have you guys thought about building out a memcache-d requirement and using memcache to store that huge manifest of file names/positions and info?

Don't you think that using memcache is a bit exaggeration for a CMS website?

Avatar
DasJacko

Community Member, 4 Posts

5 September 2009 at 5:16pm

Sure...exaggeration if we're talking about <1MM pv/month. I'm talking about high-volume, load-balanced use.

Avatar
kuba

Community Member, 5 Posts

6 September 2009 at 9:26pm

Most CMS websites are not "<1MM pv/month" ones. That's why making memcached obligatory is an exaggeration. Making it optional is something else...

Avatar
DasJacko

Community Member, 4 Posts

7 September 2009 at 5:12pm

Maybe required was the wrong choice, but if it were an insurmountable performance issue it's not far fetched IMO.

I think that any implementation worth its salt that uses any 3rd party "requirement" (in this case memcache-d) would be crap unless it had a fall back in case of unavailabilty. Using memcache-d, if you wrap a DB class with the memcache correctly, you code it to default to hitting the DB directly if memcache is not available.

I'm not sure what you're getting at...was it my semantics? Have I been sufficiently "called out" with "quotations"? :)

I was trying to explain that, if memcache were available and you used it on the sections that were causing bottlenecks (provided it's not constantly changing data ala your user profile) it makes a geometric difference in performance.

FWIW, I've hacked in memcache support for select DB calls (no pun) and have witnessed a 3.5x ability to serve non-static data with a 30 second memcache expiration (or on change expiration rules)...

Avatar
kuba

Community Member, 5 Posts

19 October 2009 at 5:20am

Ok, than you didn't want memcached as a requirement but as an option. I agree of course ;)

Avatar
Fuzz10

Community Member, 791 Posts

19 October 2009 at 7:45pm

>FWIW, I've hacked in memcache support for select DB calls (no pun) and have
>witnessed a 3.5x ability to serve non-static data with a 30 second memcache
>expiration (or on change expiration rules)...

I'm keen on learning what hack you did and how you went about it. ;-)

Having some issues with a pretty large site a.t.m..... Using APC to store pre-rendered HTML , not the nicest of options... ;-(