Slow Admin in MU

We have extremely slow page changes in the admin portion of our MU install. It takes an average of 25 sec to change from any page to another. We have six (6) sites under one domain with sub directory set up.

We have been trying to figure out the problem without any luck. This is what we have done so far.
1. Deactivated all plugins
2. Changed all themes to Twenty Eleven so we can eliminate a theme issue
3. Removed any unused themes and plugins
4. Took down the entire site and did a clean re-install of WP which included new databases etc and made sure to follow WP instructions to activate MU.
5. Reloaded our full back-up from blogvault.net our back-up service.
6. Did trial reload on blogvault servers with little if any improvement.
7. We are on a typical shared hosting plan with StartLogic and all server settings appear to be identical to others.
8. Again deactivated all plugins and themes etc with no luck.
9. Checked compatibility of all plugins and themes with 3.4.1

Our next step is to do a full install on a VPS server from a different hosting company to see if it is in fact something with our host servers.

Our specialty themes and plugins included Headway Theme, Photocrati Theme, Cart66, and Gravity Forms plugins. Everything else is standard WP and not that many of them.

Anyone else have any ideas? Everyone we have spoken too about this problem is stumped. We sure would like to hear some other options. The only thing we have not done at this point is a complete re-create of the sites (6) and this is NOT something we want to do, but we must find a solution. 25 sec per page is nuts!!

Other people running MU - how many different sites are you running off a single MU install?

Paul

  • aecnu

    Greetings Paul,

    Other people running MU - how many different sites are you running off a single MU install?

    I have many sites 20+ running on a single MU installation on my servers without any issues at all, as a matter of fact they scream right along - no kidding.

    I would think this slowness is probably due to the server you are currently on is not configured to perform specifically with WordPress MU and therefore the slow reaction which 25 seconds is horrible of course.

    So lets see what we got there.

    I have a attached a file which you will want to download, extract, and upload to the root of your hosting account.

    Then you want to call up the file in your browser like:

    http://www.yourdomain.com/phpinfo.php

    Search through until you find:

    memory_limit and please post the values indicated there

    Next lets see what your WordPress installation is actually using though this is approximate due to it is at the moment but tells a lot using the WP-Memory-Usage plugin

    And please post the results of this for comparison.

    Please advise.

    Cheers, Joe

  • ansarico

    Joe,

    Disregard my last - figured it out.

    Memory limit is 128M in both local value and master value.

    Info from Memory Usage plugin:
    #1 going from Network dashboard page to site dashboard page
    PHP Version : 5.2.17 / 32Bit OS
    Memory limit : 128 MByte
    Memory usage : 19.57 MByte
    15%

    #2 going from one site dashboard to another dashboard page
    PHP Version : 5.2.17 / 32Bit OS
    Memory limit : 128 MByte
    Memory usage : 27.51 MByte
    21%

    #3 Going to a media library page from same site dashboard
    Memory : 27.14 of 128 MByte

    #4 Going from media page to different dashboard page - notice limit increase?
    PHP Version : 5.2.17 / 32Bit OS
    Memory limit : 512 MByte
    Memory usage : 25.8 MByte
    5%

    #5 going from last site dashboard to another site dashboard - limit change again
    PHP Version : 5.2.17 / 32Bit OS
    Memory limit : 128 MByte
    Memory usage : 24.76 MByte
    19%

    Just for grins I did a Pingdom test on the last page and got the attached information. It shows another 23.14s experience.

    I hope you can have some recommendations with all this information. I found it interesting that on one of the examples above I had a 512 MB limit but on all the others it was only 128. What is that telling us>

    Thanks for all your help.

    Paul

  • aecnu

    Greetings Paul,

    Thank you for the additional information which proves the memory plugin is not very accurate.

    This is the third time I have suggested using it and it appears that it is inaccurate because the phpinfo.php reading is absolute and tells the actual server configuration setting versus the plugin which I do not know how they come up with there numbers but it is impossible for to be above 128MB unless perhaps that one site is on a different server?

    But it is certain that the phpinfo.php is absolutely correct and 128 should be enough to power your projects without a problem considering they are not executing even 50 percent of the available php process memory.

    I like the 512MB though, that is what I configure my own servers at 512MB as you can see I practice what I preach: http://wpmu-hosting.org/phpinfo.php

    Now this being a shared account we cannot see what the specs are to make a final determination in which we would need root access.

    Root access would tell us the actual server load and we could run your sites to see what load they are putting on and also that of the other shared accounts on your server. It may be necessary to get a better package or server depending on the package that you have i.e. more processor power etc.

    However, since we cannot see a "Top" through ssh with root access it is almost impossible to be certain.

    Does your current host provide a public disclosure of limiting the amount of shared accounts or VPS's on a single server?

    Please advise.

    Cheers, Joe

  • ansarico

    Joe,

    Some more information. Talked with our host (StartLogic) and there is no specific number for the accounts on a shared server. The way they handle it is each of us if given 25GB and if we start to push or exceed that number they will contact that party and get them to move to a VPS server which would be on a single server.

    In talking with the VPS techs his suspicion is that we have some javascript that is running over and over with each request. He suggested I look at the Query log to try to find out where it might be and then attack from that direction. I went to the DB but haven't found the Query log, but did find the Query Cache and I've attached some screen shots of the pages with color - indicating some out of the ordinary activity. Maybe you will understand that more than I do, but red doesn't look good on some of these pages.

    They also suggested either a firefox "firebug" plugin or the yslow plugin. I'll look at these and post the information I get from that. Their feeling was that I did not need to go to VPS but rather fix the possible JS scripting problem. Since I'm not experienced in this area - any recommendations of the best way to address this?

    Thanks
    Paul

  • aecnu

    Greetings Paul,

    Thank you for this additional information, though they may be accurate in the possibility that it may be a runaway script or something, they still base there hosting solution completely on space disregarding CPU and Memory needs.

    To stress my point as this being a bad policy, lets say you have two servers that are identical except for there Hard Disk Drives. One server has a 500 GB hard disk drive and the other has a 1000 GB hard disk drive.

    This means that the server resources with the 1000 GB hard disk drive has it resources split by twice as many accounts. So they therefore base there profit on the servers space rather then on its performance or actual resources.

    However, at this point we do not know for sure yet if they have indeed over allocated the resources of the server you are on.

    I am sorry to report that your attachment graphic did not make it to this post.

    Why don't you try this :slight_smile:

    While you have your WPMU admin panel in the browser, FTP in and rename the plugins folder /wp-content/plugins to something else and then do a test to see if the speed increases significantly.

    If this indeed works then you want to go and rename the plugins folder again plugins and deactivate all the plugins.

    Next would be to re-activate each plugin one at a time, testing in between, to see which one is causing the load.

    The above is provided that when you do rename the plugins folder that performance indeed substantially improves.

    Please advise.

    Cheers, Joe

  • ansarico

    Joe,

    Ok, I'll do the renaming of the folder and see what happens. As far as deactivating each of the plugins and then reactivating each one. I did that with no success, but I'm happy to try it again if we see some speed increases with the folder changes.

    What do you think of the concept of the scripting issue? Valid consideration?

    I did the yslow on a page and it shows that I should seek employment as a greeter at WalMart. It says I got a D on HTTP requests, an F on CDN, an F on expires headers, an F on compress components with gzip, an F on cookie free domains and an E (not for excellence) in configure E tags. Everything else was mostly A.

    Just for info, I've been doing my ftp with filezilla rather than the WPMU dashboard. Didn't know I could do it that way. Recommendations?

    I'm trying to attach the Query info again and don't know if I can copy the yslow for you.

    Looks like I need to look at the CDN setting for my Super Cache as well. SL has been pushing W3 cache vs Super cache but in my research people seem to say Super works better for a MU install - your opinion?

    Thanks again,
    Paul

  • aecnu

    Greetings Paul,

    Thank you for your additional input, it is certainly appreciated.

    If the renaming the plugins folder does not help then activating and reactivating the plugins will not matter since by renaming the plugin folder is essentially deactivating all the plugins at one time.

    What do you think of the concept of the scripting issue? Valid consideration?

    Check the root of your hosting account to see if there is an error log there, and if so what is contained within and if it's data runs through today. Please advise.

    I did the yslow on a page and it shows that I should seek employment as a greeter at WalMart. It says I got a D on HTTP requests, an F on CDN, an F on expires headers, an F on compress components with gzip, an F on cookie free domains and an E (not for excellence) in configure E tags. Everything else was mostly A.

    The Walmart thing is totally hilarious, I hope you did not take offense. However, I do not use a CDN myself so I got an "F" on that but it was my only "F" on this site in which I was curious to see the grade on it because others I have designed are similar.

    I usually use Page Speed for this type of information.

    Just for info, I've been doing my ftp with filezilla rather than the WPMU dashboard. Didn't know I could do it that way. Recommendations?

    Personally I do not like File Zilla and I use a software called Leech FTP for FTPing.

    Normally I do not use the dashboard for uploading plugins etc. Actually I have never done this, preferring to FTP it so I can see if there are any problem files, files that did not make it, or compare file sizes.

    Looks like I need to look at the CDN setting for my Super Cache as well. SL has been pushing W3 cache vs Super cache but in my research people seem to say Super works better for a MU install - your opinion?

    Oh this opinion has gotten me in trouble in the past because what I had said was used out of context --> I prefer beef over BS in which they tried to apply it to something else when the topic was clearly about caching. I do not use any caching at all preferring CPU power and leveraging the end users PC exponentially increasing the power within the network.

    Please advise on that error log and is your hosting using cPanel by any chance as the hosting control panel?

    Cheers, Joe

  • ansarico

    Holy Cow Joe!!

    Not only do I have to work at Walmart but now I'm going get a bad rep for hanging around with a rebel!! No cache, no CDN, not uploading through dashboard??? My conception of the stable universe is shattered. LOL

    As far as my homework for today, yes I did change the plugin file name and no it made no difference at all. So that is back to normal.

    Yes I do have access to the error log and I've printed it and added it as an attachment along with the DB query (again) that I split into 3 separate files to see if I can get it to you.

    The control panel at SL seems to be a typical cPanel installation.

    I had another problem that was lurking along with this slowness and that was the fact that Headway Theme would not upgrade through dashboard. So this morning I deleted it and after doing so found it did not remove the directory or files from the Theme folder. So I manually deleted it and then re-installed it to my WP and now it shows current and seems to be operating normally. Some kind of gremlin there as well. But after all this, still no speed increase.

    Maybe after you look at all the attached information you will have some more ideas. If the information doesn't come through this way, do you have an email I can send it too?

    Since I'm associating with a rebel anyway, what do you think of this idea as another possible way to trouble shoot the problem? Is there an easy was to dismember this installation piece by piece and still be able to put it back together? Just for grins and jollies, I did another separate WP install on another domain I wasn't using. Can we take sections or even pages from this domain and move it to the other until we find the page or section causing the issue? And, if so, what would be the best way to test each movements effectiveness? And of course the overall concern is, can we put it back together again into a functioning site?

    Since I don't totally understand all that I'm reading in the documentation we are looking at, I'm just trying to find a workable plan to proceed. This may be completely off base and a waste of time. We could re-create the whole site but if I don't know what we did wrong I'm not sure we won't be back to where we are now after tons of work.

    So again, your thoughts and opinions sir!

    Paul

  • aecnu

    Greetings Paul,

    Thank you for the additional input, it is once again appreciated.

    As far as that email goes aecnu (at) incsub.com is the one.

    Please be sure to put a copy of this tickets URL within:
    https://premium.wpmudev.org/forums/topic/slow-admin-in-mu

    Yes I am somewhat of a Rebel here on WPMU Dev and in life as well, prefer the tried and true versus the gimmicks and money leaking items.

    I seen through the "Cloud Computing" BS and stick to proven methods, some of my own device, and prefer what I know works over what might work :slight_smile:

    Note: I do most of my updates of plugins, themes, and WordPress through the control panel! .... lol

    But initial installations always via FTP and FTP for those items that need to be FTPed i.e. Multi DB etc.

    I have found cache to be not only a possible security leak for Membership sites etc, but also to not give a true picture unless it is cleared and though cache may reduce the php processes by serving up html and other such schemes, I found the Processor power and adding the power of the clients computer into the equation to be the ultimate, slamming those compressed pages to their browsers and their machines power decompressing them.

    This is not to be confused of my opinion of Processor cache, L2 cache, and hard disk drive cache which are not facing the web and external manipulation.

    Definitely thought provoking??

    Look forward to hearing from you and receiving those error reports.

    Cheers, Joe

  • ansarico

    Joe,

    Thanks for all your help. We ended up using the P3 (Plugin Performance Profiler) http://wordpress.org/extend/plugins/p3-profiler/ and from that could determine we had some issues with our basic WP core install. Core times were ridiculously high.

    This information, along with your previous suggestions on how to determine our host server performance really helped us out. We ended up with a fresh WP install and so far, everything is progressing nicely as we recreate our site.

    Thanks again for your help.

    Paul

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.