New to the community? Start here

Performance of WordPress admin interface

I have splited the db into 4096 databases and now the performance of the individual blogs have improved by heaps and bounds. But this has caused a side-effect for me. Now my WordPress admin interface is too slow and most of the PHP timesout. I have increased the timeout period to 60 seconds but even then it is too slow.

It will be really helpful for me to know whether anyone else have faced this problem before and if yes then how did you solved it. Thanks!

Sat, 17 Nov 2007 18:01:09
  • drmike
    • DEV MAN’s Mascot

    Strange. Any specific page you’re having this issue in? Have you optimized your dbs anytime recently? I’ve got a script that will optimize your dbs all in one batch as long as the username, password and server are the same on all of them. (It does all the dbs that account has access to)

    Give me a bit to switch computers and I’ll post a link to it.

  • Sudar
    • WPMU DEV Initiate

    Thanks doc,

    The page which is hit most is the page under Site Admin tab which lists down the blogs which are available.

    I haven’t optimized the dbs after I have created them. I have the same username and password for all the 4096 dbs and it would be really helpful if you could share the db optimize script. Thanks once again dr mike.

  • drmike
    • DEV MAN’s Mascot

    Here’s the file: [link removed – drmike]

    Drop it into root or, like me, a subdirectory under root. You have to modify the mysql information as normal. $dummy_db should be set to your global database. And change it from a *.txt to a *.php of course.

    Please note that that is not GPLed as far as i know (My personal host came up with it and I’m not sure if she wrote it or found it) so it’s not releasable.

    Most of that data I believe is coming out of the blogs db table. The only thing that’s not is the user column (ie the username and the email address) and even then, it’s still coming out of other global databases, not the individual ones. Well, it should be. I don’t have a copy handy to double check but that’s what it should be doing. Strange actually.

    You do have it set to display only 50 blogs, right?

  • Luke
    • The Crimson Coder

    You know, something I’m wondering…

    Why couldn’t there be a script that automatically optimizes a users tables every so often?

    For example:

    • get_option(‘db_last_optimized’:wink:

    • run a check say, once a week

    • use traffic to trigger it

    • update get_option once run

    That would make the most sense to me. Let it do it in small chunks, on its own, and forget about it.

    As a note, this is standard functionality for SMF. Which I had actually forgotten about until digging around in it earlier today.

    “Might make for a nifty little add-on script for the multi-db plugin.” :wink:

  • drmike
    • DEV MAN’s Mascot

    Not a problem. Please let us know if it improves your situation.

    When you run it, it will output in your browser what it’s doing. It’ll tell you which databases it’s going through. If you see actual table names within those dbs, those are the ones that are not optimized. If you see a lot of table names, then you know that optimizing needed to be done.

    I just run it manually every so often. You could set it up via a cron but I’d rather see the output.

  • Luke
    • The Crimson Coder

    Another possibility would be that “maybe” there is a lot of extra crap being loaded in the source.

    Plugin styles, scripts, and a ton of other useless s**t that is only needed in a few areas, but loaded all the time. (OK, I’m guilty of that too on occasion.)