Apache2/http + MySQL/Wordpress loading issue related to socket timeout


Staff member
I have a strange problem that is related to default_socket_timeout in Apache2/php - but it only happens in conjunction with a MySQL connection and more specifically with Wordpress.

Basically, any time I load our Wordpress, it gets "stuck" and doesn't proceed with the request. If I try again (reload) or press ESC and open a new browser, the new connection loads instantly. I believe there's something wrong with the "first" connection and subsequent connections are fine (until the cycle starts over), but I can't figure out how to fix this. I haven't been able to find a similar issue anywhere so I assume this is a rather unique situation.

The connection problem originally lasted exactly 60 seconds, after which it loaded the site (fast). This lead me to investigate php/MySQL settings, and I found out that changing default_socket_timeout in /etc/php5/apache2/php.ini affects the problem. I've now changed this value in a .htaccess file that I've put in the Wordpress directory, and this makes the problem more bearable ( php_value default_socket_timeout 13 ).

However, this is not an ideal solution, so I'd greatly appreciate if somebody can shed some light on the issue.

You can test this for yourself at <a href="http://frozenbyte.com/test_wordpress/" rel="nofollow">http://frozenbyte.com/test_wordpress/</a> - most likely you'll get 13 seconds of "Waiting for..." and then it loads. This is a 100% standard Wordpress installation.

The site is on a virtual host and I have shell access (I don't however have access to phpmyadmin). I can post php.ini values, although I firmly believe they're all default. I haven't found out anything suspicious in the log files either but I'm no expert on that. I haven't installed/done the config for this server (and my skills are limited anyhow) so I don't really know any of the inner workings that well but I assume it's fairly standard.

A little more background:

This problem used to happen with everything that had anything to do with the database (e.g. phpBB, and especially some custom but simple database scripts), but somewhere along the line it seems to have become a Wordpress-only problem. The problem should not be related to load or any other such thing, and it's not related to the time of day. It's been like this for at least two years. This problem started with the first Wordpress installation, although if memory serves, everything used to work just fine (many years ago). Now it affects all Wordpress installations (I have three running, with different table prefixes). I'm 99% sure the problem isn't with MySQL as such - using an external MySQL database does not help. The server/host has been updated by the provider over the years, and I suspect perhaps one of those updates might've introduced this, and perhaps a later update fixed it for everything but Wordpress. Just a theory though. The provider doesn't really have any clue on this either, I'd probably need to ask something more specific.

In some tests, enabling Developer Tools in Google Chrome have helped to alleviate the problem (so that it happens less frequently), but in my own tests I can't really see much of a difference. This happens on all browsers (I've tested Firefox2/Firefox3, IE6/IE7, latest Opera, latest Chrome).

Disabling/deleting all .htaccess files doesn't have any effect.

Regular non-MySQL web pages load perfectly fine, including some complex php pages - just check the root site for example (it doesn't have a link back to Wordpress though). Also phpBB (/board ) runs fine nowadays (but it too used to have the same issue to a lesser extent, no idea when/why those disappeared).

So I'm at a loss here. All help much appreciated!


Sounds like this could indeed be related to DNS issues/MySQL privileges... I still can't make it work though.

Here's the two grants I added (as per <a href="http://slackwiki.org/MySQL" rel="nofollow">http://slackwiki.org/MySQL</a> ):
GRANT ALL PRIVILEGES ON database.* TO 'dbuser'@'hosts-ip' IDENTIFIED BY PASSWORD 'passwordhash';

GRANT ALL PRIVILEGES ON database.* TO 'dbuser'@'frozenbyte.com' IDENTIFIED BY PASSWORD 'passwordhash';

Here's the /etc/hosts: localhost localhost.localdomain

195.xx.xx.107 frozenbyte.com

Wordpress only has the dbuser stuff (e.g. define('DB_USER', 'dbuser');) but I'm not sure if I'd need to use some other user here, like www-data or something...

Wordpress host is 'localhost'. If I change that to '' the behavior is the same. 'frozenbyte.com' and '195.xx.xx.107' cause the site to load infinitely and end with a white page (after 60 seconds I'd say).

Edit 2:

I've now seemingly given mysql all the permissions it needs, but still no change. Here's what I've done:

GRANT ALL PRIVILEGES ON database.* TO 'dbuser'@'%' IDENTIFIED BY PASSWORD 'passwordhash';

mysql> select User,Host from mysql.user;<br>
| User | Host |<br>
| dbuser | % |<br>
| dbuser | 195.xx.xx.107 |<br>
| dbuser | frozenbyte.com |<br>
| debian-sys-maint | localhost |<br>
| dbuser | localhost |<br>
| root | localhost |<br>
6 rows in set (0.00 sec)

mysql> flush privileges;

I think this should now be correct, or at least not cause any privileges issue.

The possible DNS issue and how to approach that I have yet to figure out - any tips would be useful.

Edit 3:

Ok this gets puzzling. By using 'show processlist;', I found out that MySQL is actually Sleeping during this non-connecting period. Here:

mysql> show processlist;<br>
| 88752 | dbuser | localhost | database | Sleep | 13 | | NULL |

When that 13 seconds, or whatever I set out in the default_socket_timeout, is up, then MySQL will process the query. I read a bit about DNS issues and it sounds like they would produce a different kind of command (such as 'Connect' instead of 'Sleep'), so therefore I think this is not related to DNS problems.

Does anyone have any clue why such a Sleep process would be initiated? Someone was having a similar issue that was apparently caused by session_start() in php, and solved with session_save_path(), but I put "php_value session.save_path /mypath/" into my .htaccess file and it didn't help anything, so this is probably a similar but not the same problem as that user was having...