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

Saving a page takes up to 15 seconds


Go to End


8 Posts   930 Views

Avatar
smio

Community Member, 1 Post

9 October 2013 at 12:43am

When saving a page in SS3 the saving process takes up to 15 seconds. From the POST EditForm to the answer of the POST Ping. Is there any way to speed this up? Any idea why this takes so long?

The website is not very big (probably about 200 pages), using the Multilingual Module, the speed is rather stable across different pages.

Avatar
Sygmoral

Community Member, 46 Posts

12 January 2014 at 3:28pm

I have the same issue. Anyone have any comments? Is it supposed to take that long to simply save a page?...

Avatar
martimiz

Forum Moderator, 1391 Posts

13 January 2014 at 12:50am

Would you say it's an overall speed issue - does logging into the cms and/or switching section take a long time as well? Is the website slow as well? Or is it just writing actions? Do you have the same problem in other browsers?

Avatar
Sygmoral

Community Member, 46 Posts

13 January 2014 at 3:23am

Thanks for your reply!

I have the feeling it's by far mostly the writing actions. The pages load in ~400ms and logging in takes 500+500+500 seconds (since it redirects twice).

But any AJAX load, it looks like, is slow. As soon as I get that blue loading icon, I can expect to wait a while. The following durations are taken from what FireBug reports:
- Loading a page to be edited takes about 900ms (which is not bad)
- When I save the draft for the same three pages several times, I get the following load times in seconds: [3, 2.5, 5], [4, 5, 1.5], [4.5, 5, 1.5]
- When I "save and publish" those same three pages: [7.5, 9, 4.5], [11.5, 8.5, ERROR], [5, 6.5, 10]

I would say 3s is acceptable enough (although that is subjective), but anything over that can start feeling a bit frustrating. And I don't want to frustrate my client :)

The ERROR is when EditPage never returned, even after two minutes, so I "timed it out" myself. Not sure whether the edit actually went through or not, since I didn't change anything. That's another issue I've had from time to time: SilverStripe's frontend simply stops working, and I have to reload the page to 'fix it'.

They are very, very simple pages by the way, and there's currently only ~20 pages total in the entire website. I am currently the only person putting any load on that webserver since it's a new one, currently only used for the development of this website. It has a single 2GHz CPU and 1 GB RAM (which I know is not much, but it will not be a very high-load website). PHP gets up to 128MB for each process.

Software versions are Apache 2.4, PHP 5.5.8 and MySQL 5.6.15. I installed them with Directadmin / CustomBuild 2, all standard settings.

The entire database is about 3.3MB. I did notice for the first time that it's using latin1_swedish_ci collations while I normally prefer utf8_general_ci, but that can barely matter of course.

Avatar
Sygmoral

Community Member, 46 Posts

13 January 2014 at 3:37am

Edited: 13/01/2014 3:57am

I have the blog module, and updating a blog post on the front end is much faster: only about 500ms, while it takes at least 2.5-3 seconds in the CMS.

While testing this, and testing different browsers as well, I started noticing large differences in load times. I thought it might be dependent on the page types, but in the end it just seems like "sometimes" it loads much faster (2-3 seconds, even 1s at times), rather than the 5-12 I was consistently getting above. So I would for now conclude that it does not depend on the browser, or on the page type, but I'm still unsure what it -does- depend on ... (FireBug being on or off does not seem to matter either)

Avatar
martimiz

Forum Moderator, 1391 Posts

14 January 2014 at 1:48am

On my (local, osx mamp) system it takes about 500ms to open a page for editing, and 1500ms to save and publish. More then one third of that time is for reloading the SiteTree - on a very small test site with about 7 pages.

That's about a factor three, as opposed to your factor eight... Have you tried on another platform yet? Then this might be something worth profiling...

http://doc.silverstripe.org/framework/en/topics/debugging#profiling

I've just installed xhprof, but not tried it yet. Maybe others want to share their experiences?

Avatar
martimiz

Forum Moderator, 1391 Posts

14 January 2014 at 1:58am

Having said that, I realize that your server iseems to be equipped with the newest software. I think most of us might still be on php 5.3, and there have been issues reported with apache 2.4 as well... Also you say it's a new server, there is no other load. Yet there are big differences... So is it a dedicated server? Can it be that the bottleneck is somewhere else on the network? Did you build/configure the server yourself? So many options... :)

Avatar
Sygmoral

Community Member, 46 Posts

15 January 2014 at 4:44pm

Thank you for the suggestions! I looked up those profiling tools, and apparently there's a newer version for xhprof, now called xhgui, and supposedly a lot easier to use. I will be trying that out soon for sure.

I had not realized that using the latest apache and php versions could possibly be a bad thing for performance. I imagined it might impact backwards compatibility, but could only be a good thing as far as performance is concerned. Guess I might be able to be more sure about that when I can inspect prospection results.

I did not build the server myself, and it's a VPS, but at a really great company that handles this very well, they can guarantee dedicated resources to each VPS. So well, I'll be curious to find out what the slowdown is coming from. And if I find something shocking, I'll come and post it here of course.