The MU forums have moved to WordPress.org

Backend very slow after upgrade (27 posts)

  1. ianbeyer
    Member
    Posted 14 years ago #

    Since upgrading to 2.8.4, My users have a very hard time accessing the back end. It works correctly other than taking several minutes to load any given page.

    Front-end works fine and responds quickly.

    Any ideas what could be causing this? It's not a resource issue on the host system. This only happened with the 2.8.4 update.

  2. wilecoyote
    Member
    Posted 14 years ago #

    I have the same issue.

    My MU front-end blog access displays quickly and correctly. The back-end, however, takes > 30 seconds to load, if at all. Sometimes, it even displays a download dialog box for the .PHP files, rather than parsing the file.

    A wp install accessing the same mysql server does not have any issues. Both the single wp install and the wpmu install are running identical plug-ins.

    For troubleshooting, I enabled debug, accessed the mu back-end, and get errors about invalid keys in some core files that deal with plug-ins. I am currently enabling one plug-in at a time to determine the culprit.

    PS. A related pet peeve is the lack of documentation regarding wp vs. wpmu plug-in compatibility.

  3. wilecoyote
    Member
    Posted 14 years ago #

    I should also add that both the single wp install and the wpmu install are on the same lamp server. Both the wp and wpmu mysql databases are on the same server, but a different server than my web server.

  4. tim.moore
    Member
    Posted 14 years ago #

    You should check into your PHP memory limit. By default on most servers, this is set at 32MB. You should up this to 64MB or 128MB, at least. You can do this for WordPress only by adding this line to your wp-config.php:

    define('WP_MEMORY_LIMIT', '64M');

    or

    define('WP_MEMORY_LIMIT', '128M');

    PS. A related pet peeve is the lack of documentation regarding wp vs. wpmu plug-in compatibility.

    This is more on the plugin developer than on the WordPress plugin repository. Some folks don't develop for WPMU as they only use WP. And vice versa. It's usually fairly easy to customize a plugin to make it compatible with both sides, though.

  5. andrea_r
    Moderator
    Posted 14 years ago #

    We've been writing about wp / wpmu plugins over at http://wpmututorials.com.

  6. wilecoyote
    Member
    Posted 14 years ago #

    Thanks for the info, Tim. I had already increased the memory size prior to the issue. It hadn't changed the performance of the offending plug-in (still lookin' for the one, assuming it is a plug-in error).

    Andrea_r: Thanks for the link. I had read that article specific to wp & wpmu a number of days ago. No offense, but I did not see where it addressed any specific differences between writing a plug-in for wp vs wpmu. I keep reading articles and forum posts, however, that state there is little or no difference writing a plug-in for wp vs wpmu.

    Nonetheless, the difference I see is that each of the active plug-ins are running on both a wp and a wpmu install (plug-ins are identical, i.e., versions, etc.), where there is no issue on the wp install, only the wpmu install. So there has to be a difference in the way wpmu incorporates these plug-ins vs the way wp incorporates them.

    For example: It could be something as simple as the time required to query each of the wpmu sub-domain database tables vs. the single wp database table, or an internal function call specific to wpmu and not wp. I don't know. I do know that I keep reading about other people wanting to know about a wp/wpmu plug-in compatibility listing. I do not understand why such a listing would be requested if no differences existed.

    I have been a programmer for over thirty years, so I eventually will find out what is causing this problem. Whether it is due to a server configuration setting, improper function calls, pilot error, whatever, makes no difference to me. I'm not looking to assess blame, rather to find a solution and share that solution with others.

    I welcome any and all suggestions and I appreciate the help and the time y'all have set aside to assist others on this forum.

  7. tim.moore
    Member
    Posted 14 years ago #

    Can you give us a list of the plugins you are using?

    Also, if you install plugins in WPMU under the plugins folder, WPMU should treat them the same as WP does. It's only when you install plugins in the mu-plugins folder that plugin handling changes.

  8. andrea_r
    Moderator
    Posted 14 years ago #

    The reson there's no definitive list of "do X for Y in MU instead of WP" is varied.

    If a plugin fails in MU and not in WP - it depends on the plugin. How did it fail? Also, I have seen many, MANY posts about people complaining a plugin "didn't work" in MU when it worked just fine - it just didn't magically gather sitewide information from all blogs like they thought it would.

    One of the posts we wrote was about options pages not saving properly in MU. That is more the result of thsoe plugins being coded with old methods - like for 2.6, which never worked in MU.

    "Nonetheless, the difference I see is that each of the active plug-ins are running on both a wp and a wpmu install (plug-ins are identical, i.e., versions, etc.), where there is no issue on the wp install, only the wpmu install."

    Again, it depends on the issue. There's as many points of failure as there are plugins.

    " So there has to be a difference in the way wpmu incorporates these plug-ins vs the way wp incorporates them."

    Like Tim stated above, only if they go in the mu-plugins folder. and if you're putting a plugin written for single WP in the mu-plugins folder, then you're asking for issues.

    part of the reason we DO have a blog to post tutorials about, is to share this info. If there was such a huge difference, and a consistent number of things to change/worry about/tweak/ we've written it already. but again, "it depends". :)

  9. wpmuguru
    Member
    Posted 14 years ago #

    "No offense, but I did not see where it addressed any specific differences between writing a plug-in for wp vs wpmu. I keep reading articles and forum posts, however, that state there is little or no difference writing a plug-in for wp vs wpmu."

    No offense taken - I didn't explain differences because the point of the two posts was to show plugin author how to write a plugin so that the same plugin works in both WP & WPMU.

  10. tomaltman
    Member
    Posted 14 years ago #

    Hey wilecoyote (and maybe ianbeyer) - we are having a very similar issue.

    We ran a sniffer on the browser and found exactly what you are describing. "The back-end, however, takes > 30 seconds to load, if at all." And found a hang-up someplace at the database level. it is not a query, almost more of a lock.

    The other clue is it seems like it is only an issue when a person is logged in. We have used a plugin called "Category Access" in the past, it has a lot of access stuff (hence the name) tied to it. We're going to look more at that.

    We're still investigating - I'll let you know what we find.
    tom

  11. andrea_r
    Moderator
    Posted 14 years ago #

    Quick stab in the dark - are your sites localized as well?

  12. tomaltman
    Member
    Posted 14 years ago #

    andrea - how would I know?

  13. andrea_r
    Moderator
    Posted 14 years ago #

    Localized, as in: do you have any non-English language packs installed?

  14. SteveAtty
    Member
    Posted 14 years ago #

    As others found, I've turned off Googlegears in my browser and its faster. But its still a bit like treacle in places.

  15. tomaltman
    Member
    Posted 14 years ago #

    We are not localized. (to my knowledge) ;)

  16. tomaltman
    Member
    Posted 14 years ago #

    We have narrowed the "issue" down a bit.

    Not that interesting.
    This an issue we believe has something to do with 1 of 5 of our wp_X_posts table.

    More interesting
    It only happens for post which are currently "live" or published. If the post is a scheduled date - it will publish very quickly.

    ********************

    OK - eagerly awaiting your responses! :)

  17. tomaltman
    Member
    Posted 14 years ago #

    We've got it whittled down one more step. It doesn't appear to be a MySQL problem. It appears to go out to MySQL - get the info and then hand it off to the php process - which is in turn slow.

    Any help would be appreciated.

    Thanks,
    tom

  18. tomaltman
    Member
    Posted 14 years ago #

    Hey ianbeyer...I think I fixed my issue.

    Tell me you also have/had Google Sitemap Generator installed...please.

    I just disabled mine and it seems to have helped. Just checking it to see if it helps you too.

    The Google plugin was calling a large number of the posts in the database each time an edit happened. At current count, we were loading about 14,000 and then it would hand those off to the php and the php process had no idea what to do with it.

    OK - let me know,
    tom

  19. andrea_r
    Moderator
    Posted 14 years ago #

    Yep, depending on what sitemap generator you have, it can be a real dog.

  20. tomaltman
    Member
    Posted 14 years ago #

    I think the Google sitemap plugin is OK - but I think there are settings which may cause it to behave poorly when there are thousands of articles involved.

  21. kgraeme
    Member
    Posted 14 years ago #

    andrea_r, any sitemap generators that you prefer? I was just about to start looking at some.

  22. andrea_r
    Moderator
    Posted 14 years ago #

    I prefer not to use them unless an explicit case is made. :)

    ie; "Google didn't crawl this page when it should have"

    most of the time, the site gets crawled just fine without it. I did, however, like the look of this one:
    http://wordpress.org/extend/plugins/sitemap-generator/

    I only did brief tests, months ago so I don't know what kind of load it generates. (which, I guess, is kinda the point. crap.)

  23. andrea_r
    Moderator
    Posted 14 years ago #

    "there are settings which may cause it to behave poorly when there are thousands of articles involved. "

    And generally on a MU site, you've got thousands of posts when you consider all the blogs.

    Good content trumps all.

  24. tomaltman
    Member
    Posted 14 years ago #

    Yea - it tells you in the fine print...but one of our data team made an adjustment, which it turn caused it to reload after each post was edited.

    From the dev site:
    • Enable manual sitemap building via GET Request
    This option allows you to refresh your sitemap using a special URL which is displayed when you click on the "[?]" sign. This url can be used with a cron job for example which refreshed the sitemap every day or every hour. This mode is preferred if you have thousands of post and the automatic building needs to long.

  25. kgraeme
    Member
    Posted 14 years ago #

    Cool, even before you quoted that bit I was thinking a daily cron job might be a better way to go. Let us know how it goes if you do change it. There have been several threads about slow backend after upgrade lately so it would be good to identify a known culprit.

  26. gazouteast
    Member
    Posted 14 years ago #

    aaargh - you're going to keep me awake all night now - the cron v each page load issue related to something I did a couple of years back and I can't for the life of me remember what it was now - but it sure made a heck of a performance difference, I remember that much - but can't even remember which script it was for. Dammit - that'll bug me all night now.

    LOL - who said senility is a gradual process?

  27. gazouteast
    Member
    Posted 14 years ago #

    I remember now - LOL

    It was in the SMF forums script, and related to the old RSS feed poster plugin over there - it had the option of a "fake" cron each time a page was loaded by a browser (or search engine crawler bot as it later turned out - talk about cyclical cause and effect) or do the stuff and use a real cron.

    The fake cron was OK during site development with just the site developer online, but by the time 2 or 3 people were on-site at the same time, it completely killed performance with number of queries per page load going through the roof.

    It was good early lesson for me about the importance of balanced scheduling of "real" cron jobs, rather than per page load crons .... dare I say - like WP-cron for example?

    Gaz

About this Topic

  • Started 14 years ago by ianbeyer
  • Latest reply from gazouteast