After upgrade to 2.7 – very slow

Hi,
I made upgrade WP2.6.5 to 2.7 and now I have problem with slow page loading – it takes 60 seconds. I installed WP Tuner plugin and I see problem with widgets_init load time:
Page Generation Performance:
marker: widgets_init time: 60,013.0ms (= 60sec)

I installed new blank version of WP2.7 and I have the same problem with load time of widgets_init.

Thanks for your help
Paul

Just a note: Sometimes my (public) web page doesn’t load at all (original post). In these cases, my browser reports the following:

“No suitable nodes are available to serve your request.”

I’m not sure if this might be a clue …

For those experiencing a slow dashboard in 2.7, try deleting all your spam comments. This causes the “Recent Comments” box to load much more quickly.

I’m experiencing this problem on a new WP2.7 install. The server also has a WP2.5 and a WP2.6.1 install, neither of which are affected.

Disabling the request() function in http.php with a return as described works around the problem with the mentioned loss of features.

There are two servers which are identical configurations, both produce the problem.

Debian GNU/Linux 4.0 (etch)
Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch13 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
Linux web01 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux
curl 7.15.5-1etch1

For the record, backporting and installing the latest libcurl3 (7.18.2-8) from Debian lenny does not resolve the problems with request(). This is the same upstream release of libcurl3 that is in Ubuntu Intrepid.

If the reported and documented slowness of both the admin pages and the public pages made with WP 2.7 continues to be regarded as a server-only problem, then this matter will never be resolved.

I have a fresh install, no plugins, no spam comments etc. etc. Sometimes the site works ok, sometimes it hangs forever. Too bad, as I really liked the features of WP and was looking forward to using it on my website. Several colleagues of mine (with lots of experience with WP, Joomla etc.) had to downgrade to a previous version, as they found the slowness unacceptable. Still, I hope the problem will be resolved somehow ??

One thing that might cause “slowness” on some requests is if your server is behind a NAT and you don’t make sure that the server is able to resolve the sites dns to a ip it could actually connect to.

Since the server, behind the NAT, can’t connect it self using the “internet ip” your DNS records points to, request to the server itself will fail which might result in rather long timeouts.
This will happen whenever WordPress decides to call wp-cron.php to do some task, and even though the read-timeout for the wp-cron.php connection seems to be very low (something like 0.01s), the fact that the “internet ip” can not be connected at all seems to cause rather long timeouts.

I’m sure there is other situations where this might be an issue too, but the wp-cron-connection was the first and only I encountered.

The easiest way to fix it (if you’ve full system access) is probably to throw in a line pointing your domain to 127.0.0.1 in your servers hosts-file.

I’m new to WordPress so version 2.7 is the first version that I’ve ever installed. I noticed that WordPress was significantly slower compared to any other applications that get served off of my local development machine. My local development machine is:

Windows XP
Apache 2.2.4
PHP Version 5.2.3 (running as CGI/FastCGI)
MySQL 4 using INNODB Storage Engine

So I looked in Apache’s error log and quickly noticed that for every page request from WordPress there were 4 of the following errors:

Error in my_thread_global_end(): 1 threads didn’t exit

To which I then started googling and came up with the following threads which offered up solutions that fixed the slowness of my WordPress 2.7 installation.

Solution 1:

Original Discussion Here
…I think its because wordpress does not know where your blog files are located. Go to your blog settings and edit the WordPress Address (URL) and change it to wherever your blog url is then hit the Save Changes button.

Solution 2:

Original Discussion Here
This error is actually a bug in the latter PHP/MySQL release, which is generated when the MySQL’s InnoDB database storage engine’s connection handlers while exiting properly did not decrement the server’s thread count. It can be fixed easily by changing/switching the PHP Server API from CGI/FastCGI to ISAPI.

Or if you want to use CGI/FastCGI PHP Server API, you can do the following to get this sorted out permanently:

1) Go to the directory where PHP is installed
2) Rename libmysql.dll to libmysql.bad
3) Download the PHP 5.2.1 binary from here and extract it to a temp folder
4) Copy the libmysql.dll from this folder to the PHP installation directory
5) Finally restart the web server to reflect the changes

So if the cause of your slowness is caused by a PHP and MySQL error on my_thread_global_end(), then hopefully these solutions should help bring your blog back up to tolerable speeds.

I’ve been watching this topic for a couple of weeks, trying every solution that was suggested, but nothing has helped. I have a number of WordPress blogs running 2.7 and it sometimes takes between 10 and 30 seconds for them to load the main page.

I’m running on the grid server at MediaTemple.net, with Apache 2.0.54, PHP 5.2.6, MySQL 4.1.11, and libcurl 7.13.2 on Debian GNU/Linux 4.0 2.6.20.2-1.

I was hoping that 2.7.1 would fix it, but I just installed it and it still loads abominably slow.

Any ideas?

guess what I’m having the same problem…
is there some official statement from wordpress regarding this problem by now?

hmmm… curious too, watching this closely because i’m having a “slow” issue as well.
-peter

Installing Disable WordPress Core Update and Disable WordPress Plugin Updates helped a lot, but it’s still much slower then before the update to 2.7.

Make sure the .htaccess file was installed with this :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

It saved me…

You can add me to the list of slow admin folks. The site loads fine, but whenever I save or update anything on the admin side, it sits “waiting for server” for about 60 seconds. Gears doesn’t really help (though once the page gets past the “waiting for server” stage, it loads more quickly). It’s not a plugin thing and happens both on a fresh install and an upgrade from 2.6. It happens in Safari, firefox 3, and firefox 2. I’ll probably install wp-super-cache and wp-tuner, but I suspect they’ll just confirm what other people have found.

I’m about to implement the php hack suggested to see if that helps, but wanted to ask: This hack disables the pinging, but are there any other important functions you lose? Also is there a way to manually ping the necessary servers on update (I know there is, I’m just not sure how to go about it)? I know it’s not the most desirable solution to the problem, but it’s driving me crazy to try to tweak a new website design and sit for a minute or so waiting to see if I need to adjust the layout again and again. Once I get out of the designing phase, I’ll probably undo the hack since the page is mostly static.

Thanks,
Matt

If I do the php hack (disable curl), it drops my time down to about 30 seconds. After installing wp-tuner, it says almost all that time is spent on “Start” (Time:31,561.4 ms with only 1.5ms of that being DB Time). Before disabling the curl all the numbers were similar except Start took 55s or more). So disabling the curl helps (I’ll see what my host has to say about that), but it’s not the only thing slowing me down.

Matt