• 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;
            }
    
             set_real_ip_from   204.93.240.0/24;
              set_real_ip_from   204.93.177.0/24;
              set_real_ip_from   199.27.128.0/21;
              set_real_ip_from   173.245.48.0/20;
              set_real_ip_from   103.22.200.0/22;
              set_real_ip_from   141.101.64.0/18;
              set_real_ip_from   108.162.192.0/18;
              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;
                    break;
                }
            #include /var/www/mysite.co.uk/web/nginx.conf;
    }

    Here’s the php5-fpm pool

    [web9]
    
    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
    extension=suhosin.so
    suhosin.executor.include.whitelist="phar"
    suhosin.request.max_vars=2048
    suhosin.post.max_vars=2048
    suhosin.request.max_array_index_length=256
    suhosin.post.max_array_index_length=256
    suhosin.request.max_totalname_length=8192
    suhosin.post.max_totalname_length=8192
    suhosin.get.max_value_length=1024
    suhosin.memory_limit=128M

    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?

Viewing 15 replies - 1 through 15 (of 64 total)
  • oh my god wordpress 3.3 is incredibly slow , does anyone experience that , better switch to old ones

    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.

    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.

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

    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.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

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

    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

    or

    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!

    See here:
    https://www.dev4press.com/2011/blog/benchmark/wordpress-benchmark-3-0-vs-3-1-vs-3-2-vs-3-3/

    WordPress 3.3 performance is show as substandard – Yikes!

    Thread Starter talkingnews

    (@talkingnews)

    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.

    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.

    Milan

    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.

    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.

    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.

    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.

    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.

Viewing 15 replies - 1 through 15 (of 64 total)
  • The topic ‘WP admin, even 3.3, incredibly slow.’ is closed to new replies.