[closed] WP admin, even 3.3, incredibly slow. (65 posts)

  1. talkingnews
    Posted 3 years ago #

    Ubuntu 11.10
    Nginx 1.0.10
    php5-fpm 5.3.8

    I've got a 256Mb VPS running a Zen Cart store and phpbb3, both in different php-fpm pools. There's hardly anything running except the essentials and both those sites absolutely rocket along. As does the front end of the WordPress site, when W3TC accelerated.

    BUT.... the admin side takes 6-10 seconds to do anything.
    There's nothing in the mysql slow log, or the php-fpm error log, the load doesn't spike, and the memory usage doesn't shoot up (but see below about memory).

    The first time it loads, at wp-admin/options.php it shows a very long page that looks wrong, with line after line of stuff like...

    active_plugins SERIALIZED DATA

    Here's the main items from ps_mem.py

    732.0 KiB +  87.5 KiB = 819.5 KiB       bash
      2.1 MiB + 369.0 KiB =   2.4 MiB       fail2ban-server
      1.8 MiB +   2.0 MiB =   3.9 MiB       nginx (5)
      5.1 MiB +  12.8 MiB =  17.9 MiB       php5-fpm (29)
     87.8 MiB + 149.0 KiB =  88.0 MiB       mysqld
                            116.2 MiB

    Here's the load average pretty much all the time:
    load average: 0.48, 0.53, 0.51

    And here's the output from free -m

    total       used       free     shared    buffers     cached
    Mem:           241        202         38          0          3         49
    -/+ buffers/cache:        149         92
    Swap:          511         29        482

    Here's the nginx.conf, including the cloudflare real_ip settings (tried without cloudflare too), and also the rewrite required to make permalinks work under nginx:

    server {
            listen 31.172.x.x:80;
            server_name mysite.co.uk www.mysite.co.uk www.my-site.co.uk my-site.co.uk;
            root   /var/www/mysite.co.uk/web;
            index index.html index.htm index.php index.cgi index.pl index.xhtml;
            error_page 400 /error/400.html;
            error_page 401 /error/401.html;
            error_page 403 /error/403.html;
            error_page 404 /error/404.html;
            error_page 405 /error/405.html;
            error_page 500 /error/500.html;
            error_page 502 /error/502.html;
            error_page 503 /error/503.html;
            error_log /var/log/ispconfig/httpd/mysite.co.uk/error.log;
            access_log /var/log/ispconfig/httpd/mysite.co.uk/access.log combined;
            ## Disable .htaccess and other hidden files
            location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
            location = /favicon.ico {
                log_not_found off;
                access_log off;
            location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
            location /stats {
                index index.html index.php;
                auth_basic "Members Only";
                auth_basic_user_file /var/www/clients/client3/web9/.htpasswd_stats;
            location ~ \.php$ {
                try_files $uri =404;
                include /etc/nginx/fastcgi_params;
                fastcgi_pass unix:/var/lib/php5-fpm/web9.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_script_name;
                fastcgi_intercept_errors on;
              real_ip_header     CF-Connecting-IP;
            client_max_body_size 28M;
            client_body_buffer_size 128k;
            if (!-e $request_filename) {
                    rewrite  ^(.*)$  /index.php?q=$1  last;
            #include /var/www/mysite.co.uk/web/nginx.conf;

    Here's the php5-fpm pool

    listen = /var/lib/php5-fpm/web9.sock
    listen.owner = web9
    listen.group = client3
    listen.mode = 0660
    user = web9
    group = client3
    pm = dynamic
    pm.max_children = 4
    pm.start_servers = 1
    pm.min_spare_servers = 1
    pm.max_spare_servers = 2
    chdir = /
    php_admin_value[open_basedir] = /var/www/clients/client3/web9/web:/var/www/clients/client3/web9/tmp:/var/www/mysite.co.uk/web:/srv/www/mysite.co.uk/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin
    php_admin_value[session.save_path] = /var/www/clients/client3/web9/tmp
    php_admin_value[upload_tmp_dir] = /var/www/clients/client3/web9/tmp
    php_admin_value[date.timezone] = "UTC"
    php_admin_value[post_max_size] = 28M
    php_admin_value[session.gc_maxlifetime] = 604800
    php_admin_value[upload_max_filesize] = 28M
    php_admin_flag[display_errors] = off
    php_admin_flag[display_startup_errors] = off
    php_admin_flag[log_errors] = off
    php_admin_flag[ignore_repeated_errors] = off
    php_admin_flag[ignore_repeated_source] = off
    php_admin_value[memory_limit] = 32M

    I had to make changes to /etc/php5/conf.d/suhosin.ini as advised by phpmyadmin, and also upped the memory limit for WP as I was getting
    "ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value".

    ; configuration for php suhosin module

    I reduced the memory limit in wp-config.php as shown below.

    define('WP_MEMORY_LIMIT', '32M');
    define('WP_MAX_MEMORY_LIMIT', '32M');

    Although, I've changed these limits from 256 to 128 to 64 to 32 and it makes NO difference to the front or back end speeds.

    I changed the theme to default, turned off all the plugins, changed all the mysql tables to to innodb and followed the recommendations of mysqltuner (even though, as I said, there's nothing about slow mysql in the logs I can see).

    I've tried changing php-fpm from socket to port and back, and so on and so forth. Not really sure what else to do now - can anyone spot anything here or advise?

    The strangest thing of all? I'm running a personal WP install on a free "tiny" instance on Amazon S3 with a similar config, and it flies along.
    Which is what makes it even more difficult to diagnose.

    And yes, I might be running a bit tight on memory, but then why does Zen Cart and phpbb running with a big DB load pages sub 200ms?

  2. aki143
    Posted 3 years ago #

    oh my god wordpress 3.3 is incredibly slow , does anyone experience that , better switch to old ones

  3. rickssekhon
    Posted 3 years ago #

    Same here aki143.
    Today morning, happily upgraded to wordpress 3.3 but everything changed. Now, my wordpress is dead slow and taking too much time in loading any page. Not only the admin area, it affected my blog also.
    3.2.1 version is the much much better than this one.

  4. Shane Gowland
    Posted 3 years ago #

    From your logs, it looks like MySQL is chewing up the majority of your resources. Have you tried adding a caching plugin to WordPress to minimize database calls?

    MySQL databases to have a tendency to slow down as they become more and more fragmented (much like a traditional hard drive.) Perhaps you just need to optimize your db tables and clean out any superfluous junk. WP-Optimize comes to mind if your not comfortable doing it manually.

  5. Shane Gowland
    Posted 3 years ago #

    The usual steps of "Re-install WordPress from fresh copy" and "Disable all plugins and themes" might also help out.

  6. chrisboggs
    Posted 3 years ago #

    Just for feedback information for the powers that be, I too am experiencing dramatic slowness and even malfunction issues after having updated WP to 3.3 45 minutes ago. Immediately after upgrading automatically I received the dreaded "Error Establishing Database Connection" message. After several retries to load the site in several browsers the site came up. The pages on the front end are loading VERY slowly, 70-80 seconds.

  7. Turn off your plugins and see if it goes any faster? It could easily be issues with SQL calls (as TheWebAtom pointed out).

  8. RogerWheatley
    Posted 3 years ago #

    It is incredibly slow on all sites (35+). Even when there are no plugins installed! All databases are optimized, etc. Just before updating to WP 3.3, all sites (and admin) were "zippy" and responded fast.

    Maybe this is an issue where the "eye candy" of the new layout and upload functionality, etc. took precedence over improved response, usability, etc.

    What can we do to either:

    1) Create a fork off WordPress, with faster code


    2) Fix the speed issue? (Remove some of the new code causing the incredible slowness).

    Case in point, I've had people complaining all day, and some have already asked me to move them off the WordPress platform (this is not good).

    Regardless, something definitely was added that is causing the painfully slow response.

    Anyone have good suggestions as to a fix?

    Thanks muchly!

  9. RogerWheatley
    Posted 3 years ago #

    See here:

    WordPress 3.3 performance is show as substandard - Yikes!

  10. talkingnews
    Posted 3 years ago #

    Right - well that kind of explains a few things.

    Two days of my life and a helluva lot of learning about things like xdebug, I can safely say you CANNOT now run WordPress on a VPS with less than 512Mb RAM. Which is a shame, because the 256Mb VPS had always been perfectly good before.

    Previously, it had been OK. You remember in my original post, I noted the line about "ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value"?

    Well, I also noted that I didn't see any memory spiking in the command line utility "top". But clearly, that doesn't refresh fast enough. With a bit of help from the VPS host who has graphical tools, we were seeing bursts of 228Mb usage when the ADMIN side of WP 3.3 was trying to load. But the front end? Well, as I said before, that zipped along and barely even registered on their graph.

    I've temporarily moved to a 512Mb RAM VPS while I decide what to do, and, of course, WP is fine again. But it's not an affordable long-term solution. So will either have to try and revert, or look at another CMS. Which is a shame, after 5 years of happy WordPressing.

    Final note to pre-empt the inevitable "but you can get 1Gb RAM VPS very cheap these days" comment, yes, you can. And I've been badly burnt that way. Amazon EC2 looks incredibly tempting - but you try not being able to stop, recover, relaunch or save a backup or even a snapshot from a failed instance for the 6 days it takes support to reply. And as for HostEurope/Webfusion, hell will freeze over and I'll start listening to Justin Bieber before I even wish them on my worst enemy.

    So I'm happy that I can just pick up the phone and immediately speak to someone, in London, in English.

  11. Milan Petrovic
    Posted 3 years ago #

    I did the benchmark Roger shared above, and I did it on the fresh installations with demo data added. But, I got few reports from client that they are getting more problems after normal upgrade (as several people posted here). At this point I am not exactly sure what is going on to cause slowdown on existing sites that worked great with 3.2 or older versions, but something is not right.

    I was lucky with my websites, I was doing tests last month on sendbox servers to make sure that I will have no problems. I monitored all changes to see if things are working out, and only issues I had is broken website due to caching plugin (took me 5 minutes to fix), slight increase in memory usage and a bit slower admin side.


  12. Jason
    Posted 3 years ago #

    Same issue here (wp-admin crazy slow after upgrade). Weird thing is the front-end is just as fast as it always has been. Backend is crazy, painfully slow. I'm going to be testing out several things and I'll post any findings I come across.

  13. slz
    Posted 3 years ago #

    I'm having the same problem as everyone else. It takes forever to go to any of the admin pages, but the actual site is as fast as ever. I didn't have this problem at all before upgrading to 3.3 from 3.2.1.

    Luckily, I did the upgrade to 3.3 in a sandbox and not on my actual site. I'll be waiting to upgrade to 3.3 until this problem is fixed.

    btw.. this is on a dedicated server with 1gb of ram.

  14. slz
    Posted 3 years ago #

    This is an update to my previous post.

    I did a fresh WordPress 3.3 install to my sandbox, and it didn't have the slowdown in the admin panel.

    I then tried disabling all of the plugins and changing to a default Twenty Eleven theme, but neither of these helped. This is with multisite enabled (if that makes a difference).

    So it seems the problem could be associated with the 3.2.1 to 3.3 upgrade process, but I'm not sure what to try next.

  15. Shane Gowland
    Posted 3 years ago #

    I think I have a solution for WP MultiSite users. It's worked for me three times now on various networks I manage.

    Go to the network dashboard and go to the "Available Updates" screen. Click the "Re-install Now" button and wait for the process to complete.

    Once the upgrade has been re-performed, go to the "Update Network" page and perform the update. If any errors are thrown, ensure they are fixed then run the network updater again.

    Once the entire network has been updated, ensure the network's primary site is running the Twenty-Ten or Twenty-Eleven theme. The issue should be resolved.

  16. slz
    Posted 3 years ago #

    Hey Shane,

    I just tried your method on my MultiSite installation, but it didn't help with my slowdown in the admin panel.

    All plugins were disabled and all themes (except for Twenty-Eleven) were deactivated.

    As mentioned in my previous posts, I upgraded from 3.2.1.

  17. slz
    Posted 3 years ago #

    Alright here's another update on this problem.

    I went back to my backup of my 3.2.1 multisite, which I made immediately before I installed the 3.3 update, disabled all plugins and themes (except for Twenty-Eleven), and used the automatic update process to update to 3.3. This didn't fix the extremely slow admin area.

    Next, I went back to my backup of 3.2.1 again, disabled all plugins and themes, and did a manual update to 3.3 using the procedure at http://codex.wordpress.org/Updating_WordPress#Manual_Update. This also didn't fix the problem.

    Not really sure where to go from here. This was originally a fresh 3.0 installation, and I've been updating it without any problem ever since--until now. Hopefully someone will figure out what the problem is.

    I have a feeling it's multisite and database related. Are the other guys that are having this admin slowdown also running multisite?

  18. RogerWheatley
    Posted 3 years ago #

    I read all the above, and tried out a couple things.

    I still experience the slow issue:

    • In multisite (test environment) AND with stand alone installations (both production and test).
    • When I upgrade from 3.2.1 to 3.3.
    • When I install a fresh copy of 3.3 in a test environment.
    • When I install a fresh copy of 3.3 in a production environment.

    And yes, I've also had an unexpected number of people complaining about the slow speed. I'm still trying to figure out what's causing this. - And it's difficult as I cannot use WP 3.3 in a production environment, yet (because clients already complained and I had to downgrade from backups).

    Still trying to isolate what is causing this...

  19. RogerWheatley
    Posted 3 years ago #

    I should note, that sites using WP 3.2.1 were on a VPS server with:

    • 2GB RAM
    • 12 Core AMD Opteron Processor 4174 HE 512M

    No performance issues until immediately after moving to WP 3.3. WP 3.3 was noticeably slower.

    The test environment is:

    • 8GB RAM
    • 16 Core Intel i7-2600K 8M, 3.40 GHz

    Noticeably slow performance with both fresh and upgraded installs of WP 3.3

    As mentioned earlier, I'm still trying to "see" what's causing this. (One difficulty, for me, is I'm not a core developer - far from it - Which makes this harder to figure out).

  20. talkingnews
    Posted 3 years ago #

    slz:Are the other guys that are having this admin slowdown also running multisite?

    Guys?! There might be female WordPress developers and users too....


    ....ahahahaha! But seriously, no, mine was just a single basic install

  21. RogerWheatley
    Posted 3 years ago #

    I'm almost wondering if this is exacerbated by scripting? (Yes, I know, it's kind of a broad statement...)

    One tiny example is the admin bar. Funnily, it's several of my clients that had pointed out the duplicate information/links were in the new admin bar. They prefered the old dashboard header. At first I assumed it was a result of personal artistic taste, however, after clarifying with some of them, many said it was "...the old top bar area was clean and not clutered with links and dropdowns and stuff..." and another "...what's with all the extra links and info in that top bar? I get the same in the big bar on the left, why are there all the links to wordpress, I don't need those there, can you move this away somewhere else for us? Thanks..."

    Granted, this (above) is a tiny issue (well, at least I think it is), rather the point I wonder, is if all the extra tools, flyouts, tooltips, bars, lightboxes, and associated scripting, are what's causing the issue? I'm not sure yet, as I've not been able to garner any facts, to see where the issue lays.

    I also know from experience that Javascript is best used with an eye on compatibility. In the past, I've often encountered issues with plugin conflicts that were a result of javascript.

    One particular area, is the upload feature. Why am I looking there? Personally I like it, as I think the Devs did a wow, gosh, fantastic overhaul of it!! :) I thinks it's more logical - no need for extra buttons ;)

    I have no idea of the reaction from the general public, I can only look at this area as my clients loudly protested about it. I don't doubt, as with many people, there is some resistance to change, I think maybe such resistance is natural at times?

    More to the point, it made me look at this and wonder if the need to load the extra scripting (is there extra scripting?), helps to cause the slow response? In particular, why load scripting to enable drag and drop, when the drag and drop only works with one file at a time? And I've yet to observe any client I visit or remotely assist use it, they always click the "Select Files" button and navigate to the file to upload. Those whom I asked, told me they don't like switching back and forth between file navigation and the web page, just to upload one (or more) files.

    Regardless of how they approach uploading of their files, it makes me wonder if this extra scripting is causing a slowdown with some other scripting elsewhere?

    Every page they load has a tooltip (until the option is disabled). Is "tooltip" contributing to the slow down?

    Why for example, when users click the "?" icon in the post editing toolbar, does a lightbox have to open - Again, this is extra resource usage (for something that is arguably for cosmetic effect).

    Without question, there are some pretty nice cosmetic effects (or at least I think they are nice), however, it does lead me to wonder...
    Is the very slow response, in great part, a result of using Javascript, etc.?

    As I mentioned before (somewhere), I had to restore all sites back to version 3.2.1, and am itching to move forward to 3.3. To that end, I hope more people can share their experiences and knowledge, so that we can isolate where the sluggishness is really coming from, and have it fixed.

    Given all the extra special effects and goodies, I wonder then, if the admin area should not have built in caching in some manner or another (to improve response time - some interface elements do not need to be recreated by PHP or Javacsript, etc. every single time) No?

    For now, I feel like I'm tapping in the dark, trying to find the issue causing WordPress 3.3 to be so very slow. So, hoping the perceptions and input, help spark ideas that people can zero in on and eliminate as a potential cause or mark for follow up.

  22. slz
    Posted 3 years ago #

    RogerWheatley, I know that you said you also noticed the slow admin area with a fresh install, but when I did a fresh install, it seemed fast--just like with 3.2.1, so I don't think the extras they added are causing the slowdown.

  23. RogerWheatley
    Posted 3 years ago #

    Update, I found this thread: http://wordpress.org/support/topic/slow-wordpress-it-drove-me-crazy?replies=29

    Could it be there is some cron issue?

  24. Jason
    Posted 3 years ago #

    I did a little bit more testing today. The things I've noticed is the VPS environments that our IT set all have the slowness, but the environment I have out on hostmonster (multisite) is all snappy. I've also tried deactiving all plugins and still no go. I'm guessing this is ultimately an issue with the default settings on a Virtuosso VPS. I'll do some more research and post my findings. Still haven't been able to confirm if this is a multisite only issue with VPS' but I'll check it out on a single install on a VPS.

    Also to note, clicking the Update Network on all my slow VPS' give this error:
    Warning! Problem updating http://domain.com/site1. Your server may not be able to connect to sites running on it. Error message: couldn't connect to host

  25. slz
    Posted 3 years ago #

    Jason, some people that have posted in this thread are also having the slowdown in the admin backend without multisite.

  26. slz
    Posted 3 years ago #

    Here's an update for everyone that's having the problem.

    I was doing the 3.3 update to a copy of my multisite in another sandbox VPS when I noticed the slowdown in the admin area. This was a few days ago.

    Well, after saving backups, I decided to go ahead and try the update on my main site to see if it also had the slowdown. The update went fine, and it didn't have the slowdown I experienced before.

    The two environments are basically clones of each other, so I'm not sure exactly what the deal is, but it's working fine now.

  27. WeeVicki
    Posted 3 years ago #

    My site also takes a long time to load. It behaves as though it is "hung up." I'm a basic user who is taking time to report to WordPress that version 3.3 is slow loading.

  28. dschmidt20
    Posted 3 years ago #

    Yeah 3.3 is a slight step backwards imho. Still love WordPress, but with the same config, optimizing tables, running w3tc w/ XCache, minifying and combining scripts and stylesheets, along w/ just about everything else it takes to improve page load speed, #page take forever to load in my twenty eleven child theme.

  29. impulse8
    Posted 3 years ago #

    Why is the admin area so slow!? I just installed a brand new version of wordpress clean install and its so slow!

    Any devs have a response!??!?!? Its just so painfully slow.

  30. rickssekhon
    Posted 3 years ago #

    Hey impulse8, I also had the same issue. But yesterday, I upgraded wordpress 3.3 to 3.3.1 and now its seems much better than previous. wordpress devs team had tried to sort out this issue which everyone has faced from the very first day and released an upgrade for it. You can give it a try, I hope it will help but dont forget to make a full backup before you upgrade your core installation.

Topic Closed

This topic has been closed to new replies.

About this Topic