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.

General Questions

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

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

CMS backend slow when lots of traffic on the site


Reply

2 Posts   401 Views

Avatar
adrian

11 July 2012 at 8:42pm (Last edited: 11 July 2012 10:04pm), Community Member, 5 Posts

Hi all,

I was wondering if anyone has any suggestions for a hosting configuration that isolates the CMS backend from the front end so that it's still performant for editing content when there's a lot of traffic on the site.

I love that I can use cacheing and all sorts of strategies to speed up the front end, in fact I'm really happy with the front end performance of my silverstripe sites, even with hundreds of concurrent users. But I find that every time there are lots of users the CMS backend slows down considerably, often timing out when trying to edit a piece of content.

I was thinking perhaps I could host a duplicate instance of the site just for the CMS on a different domain but pointing at the same database? Still it would be running on the same box and on the same instance of Apache so I don't know that it would help all that much.

I'm using v2.4.7. Any thoughts?

UPDATE: Further thinking through this idea of running a separate instance just for content editing, I also imagine the assets folder would be a challenge but perhaps solved through symlink-ing it to the live front end folder? I'm sure there's lots of other gotchas too. It quickly seems to get to the point where the two instances have to share so many server resources that it defeats the purpose.

Has anyone had any success running a separate instance just for content editing? Is there some other strategy?

Avatar
Willr

12 July 2012 at 5:42pm Forum Moderator, 5511 Posts

You could mount the assets folder as a network share between all the machines (saves having to worry about rsyncs). You may want to talk to your host about getting something like that setup. At the same time you need to decide what machine you want to put your database on, either the CMS machine or the front end and update each machine to point to that rather than localhost.