Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a WordPress site that works fine on the front-end but the backend admin pages take just over 120s to load. The page doesn't timeout - the server responds - it just takes a long time. I see no errors in the PHP or apache logs.

Obviously the 120s is a clue - I'm thinking a CURL request or something similar.

I have used mod_status to look at the server-status - I can see one process that is held in the "W" state (sending reply) for the duration of the long page load.

Obviously the WordPress page process winds it's way through many PHP scripts - how do I find out where the hold up is happening?

I have tried brute force methods of disabling plugins one by one but with everything pared back I still see the issue.



Running netstat seems to confirm it's a curl like issue;

# netstat --tcp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 myip:http                   12-34-56-78.dsl:56446       ESTABLISHED
tcp        0      1 myip:35595                    SYN_SENT

The 1st entry is my IP making the page request, the 2nd entry is the server's IP - the request is not getting through the firewall. I don't control the firewall so I need to find where in the codebase this request is originating.

share|improve this question

migrated from Jul 15 '12 at 16:14

This question came from our site for professional and enthusiast programmers.

Have you tried to use xdebug ? – j0k Jul 14 '12 at 17:22
do you have shell access to the server? you can check if there's any pending http requests (e.g. curl) by using netstat. – Marc B Jul 14 '12 at 17:23
Thanks & +1 both. Marc B netstat seems to confirm that it's a http request at fault, but doesn't get me any closer to finding the point of issue. I will try to install xdebug and use profiling to pin things down. – Paul Fernihough Jul 14 '12 at 20:34

As is often he case the answer to this one was pretty simple in the end. Running netstat confirmed that a http request was the hold up, when I spotted it was a request to the server IP itself I realised it wasn't getting through the firewall. So I edited the hosts file with the domain of the WordPress site and the internal IP of the machine...

Et viola the request can now be routed properly without falling foul of the firewall.

Thanks Marc B for the netstat tip.

share|improve this answer
you might want to accept this answer so question will be marked as answered... – eis Jul 15 '12 at 13:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.