It worked. But man alive it was slow. I mean S L O O O O O W. Any page took at least 12 seconds (actually almost exactly 12 seconds longer than the login page for example was loading on the other blogs. Comparable pages between fast blogs and slow blog were 12 seconds slower on the duff one) to display (even the login page). Non-php resources such as css, js, images were all loading just as they did on the other blogs (which themselves continued to be speedy).

Anyway, to cut a long story search I Googled myself half to death and found many such reports but no real answers. Usual solution was plugins misbehaving but this didn’t apply to me or to many others suffering similar problems.

The problem for me turned out to be DNS. Yep, that simple. The blog was at blog.domain.com. My own machine resolved this address perfectly well (obviously since I could see the blog) but a server DNS issue meant that it wasn’t being resolved on the server (I have root access and was able to ping the domain name from the server itself and witness a failure.) And guess how long it took for a “ping blog.domain.com” to time out on the server? 12 seconds.

I sorted the DNS problem and bang, it speeded up just like the other sites. So, it would seem that somewhere in WordPress there is a DNS lookup being done, perhaps gethostbyname() upon the blogs own “name”. The blog and the admin etc work perfectly but a failed attempt at name resolution somewhere adds a constant to each page load. The actual duration will depend on individual server resolvers I guess.

This could easily explain some reported problems at various hosting companies. Working blogs suddenly take 30 to 40 seconds to load then time passes and they are ok again. I may venture a patch or a plugin to WordPress to “fix” or at least detect this situation. DNS servers do pack up occasionally or a server or LAN DNS server becomes unavailable. YOu wouldn’t expect WP to have to resolve its own host name but when it can’t you have a problem.

I’m off to do a find in files for “gethostbyname” and related functions.

We recently migrated a windows 2000 Apache install to a Windows Server 2003 box.

Despite having all the mysql libs, the pho_sockets module etc configured php kept failing to connect to a mysql localhost with the error “Can’t create TCP/IP socket (10106)”

After much googling and little answers (though many others having the same problem) I realised that in my httpd.conf in the section where we set runtime values for the PHP (such as PHP_RC, TEMP FOLDER etc.) included the path C:\WINNT which of course was fine on windows 200 but on Server 2003 should have been C:\WINDOWS.

Once all these paths were changed and apache started, all was well.

My guess is that php_sockets is dependent upon windows winsock implementation and with duff paths being passed to php-cgi.exe the winsock library could not be loaded and hence all socket stuff failed.

I’m only guessing though. Whatever the reason it’s unimportant since there was a clear problem with the paths.

Hope this saves someone else a couple of hours!