Search

Lately, i've been running into all sorts of speed issues with the admin. When I try to save an entry to some sort of post on the site, it takes fooorrreeeeveerrr to save. Earlier today it would just time out on mye and return a 500 error and I wasn't sure why. Luckily I had a staging site that had the latest data which I flipped over to be my new root for production and then vise versa (obviously not ideal). I was hoping that there was some weird config in my old production stuff that I forgot about which could have bogged the site down but that did not seem like the case. I am able to save things now, albeit still rather sluggishly.

Are there any sort of performance monitoring tools I can use to help me debug what is going on? I feel like it might be one of the extensions I have installed that is doing something my server doesn't like. It could also be the fact that I am on a shared server and probably shared mysql server. Thoughts?

500er errors drop an entry in your server log files! normally under /var/log/apache/error.log in your webserver-config you can increase the loglevel, to get more detailed information.

usefull informations could be found on SYMPHONY_DIR/manifest/logs/main

Can you share a little about your setup? Server environment, PHP versions, Symphony versions, number of sections, extensions, entries, average fields per section, are there lots of linking fields (SBL/RL/SSM etc.)

There's no ?profile for the backend, but usually the above information gives a pretty good indication of how things are going :)

moma, i've been looking at that stuff and i'm just seeing this:

336 [Tue May 20 21:40:57 2014] [error] [client 111.111.111.111] Premature end of script headers: index.php, referer: http://site.com/symphony/publish/product/edit/9532/saved/

I'm not too sure what to make of this one.

brendo, sure:

I'm pretty sure it's a dumb shared dreamhost server

  • php 5.3.27 (but that is pretty standard, right?)
  • symphony 2.3.3
  • ~40+ sections (this can probably be trimmed down a little bit)
  • 39 extensions (like sections, this can probably be trimmed down since a lot of them were mainly during development and I never bothered to clean it up)
  • doing a rough estimate, the average fields per section is probably around 5-6, though there are some rather large sections. I didn't do an accurate count, but i have one that needs to list out all the nutritional facts so that one is around 25-30 fields. Then there are a few other sections with probably around 10-15 fields, but the vast majority are under 10. Some even have just one.
  • doing a quick look over the sections, there are probably around 5k entries, about 4k are for one section (stores their products are in - which I also just discovered has reached a memory limit and won't display the page...sweet)

For the "product" section above, i have the following:

  • 17 fields
  • 7 SBL fields...that's probably a pretty decent amount, I'm not really sure what the recommended number would
  • 3 filemanager fields

I think i have another section that is having similar performance issues but that only has 1 SBL and 1 filemanager field, with 11 total fields.

For the stores, i have 6 fields, but one of the fields is the Address Location extension that I had to fork and customize for my use case.

what does RL stand for?

thanks for the help.

i did some quick-ish tests and moved my client's entire site over to my dreamhost vps with 411mb memory (ya, just dragged a slider =P) and a dedicated mysql server and the product section seems to be saving fine. So that leads me to believe that a big issue has to do with them being on a shared server (i thought they were on a vps for some reason, but it was never an issue until now).

I forgot that the store section not loading issue is a problem with the Entry Order extension since it modifies the "paginationmaxrows" property to a ridiculously large number in order to allow for drag-n-drop sort ordering. Changing that number makes it work fine so that makes me feel at least somewhat better about these performance issues =)

Ok, so you're about a pretty decently sized section. 7 SBL's is a lot for one section, especially combined with 4,000 entries. This number, and the less than ideal way that SBL fields work would be causing you to run out of memory, no doubt about it. That's why moving to a larger server with more RAM has alleviated the issue. Unfortunately, it's a problem that will reoccur as the site continues to scale.

To improve your chances of the allowing the Entry Order extension to work, try and see if you can reduce the number of visible columns on the index page (particularly if they are SBL's!).

I'm sorry I can't be of more help. The SBL really has scalability issues that are a challenge to resolve!

thanks brendo. The 7 SBL is in a section that only has around 30 entries. The 4k entries doesn't have a single SBL in it (though it has the Address Location extension).

The problem with the Entry Order extension is that it affects a global pagination setting so if one section is using the extension, it will update that global setting (i believe) which will then have affect on all other sections using the same extension.

I'm not really sure if i can get around not having those 7 SBL entries in one page or not. I'd def have to rethink the relationships going on right now.

it will update that global setting (i believe) which will then have affect on all other sections using the same extension.

Not true. It affects only that section.

@vlad, what is this setting then:

'symphony' => array(
    'pagination_maxium_rows' => '999'
);

in manifest/config.php?

That's the setting. It seems that I'm wrong then. I thought it sets the limit only for current section.

Order Entries has been beefed up to overcome this. @Nils the wizkid worked a better solution out. https://github.com/symphonists/order_entries/pull/41

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details