0

I have a webserver running CentOS 5, with Apache 2 and PHP 5.3. At the moment the server is mainly used for development, so there's really no traffic to talk about. The server houses a couple of Drupal instances, a Mediawiki instance and a few static pages. It makes use of virtual hosts.

The problem is that I get really bad performance with Drupal and Mediawiki. Page execution times are somewhere between 5 and 15 s. The static pages work just fine.

I've enabled mod_forensics and I can see that requests are registered immediately, but then it takes 5-10 s before they are served, so the issue is somehow related to execution on the webserver.

I've installed the Devel module, that provides information about execution, in Drupal and it gives me figures like this.

Executed 59 queries in 62.86 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 6215.2 ms.

So database performance doesn't seem to be an issue.

I've installed eAccelerator and turned on logging, it shows hits for almost all page requests, like this:

 EACCELERATOR hit: "/var/www/adqwww/includes/path.inc"

That should mean that the cache is in use, if I understand things right.

Now I've run out of ideas, I need to pinpoint more exactly what is happening, but I really don't know how to do that. Since both Mediawiki and Drupal are affected I assume that this is related to php, but I don't know how to look into it. Any help would be appreciated.

UPDATE: The problem has now been solved (I don't know if there's a proper way to mark the question as solved), it turned out to be a DNS issue, just as suggested below. I didn't understand that the SQL server needed to resolve the connecting web server. Thank's to everyone who took the time to answer this.

Mikael Grönfelt
  • 677
  • 3
  • 7
  • 14

2 Answers2

0

This sounds like a timeout, your system is waiting for something rather than doing something.

Usually in this situation it's name resolving (DNS) (reverse lookup of the httpd/mysql, or forward lookup of the mysql host).

Check if you can lookup the IP where you connect to and the hostname where you DB connects to, and how long that takes.

Joris
  • 5,969
  • 1
  • 16
  • 13
  • By reverse lookup of the httpd, do you mean that the client should be able to resolve the hostname of the webserver using the IP adress? That is not the case at the moment, I'll check that out. At the moment it looks like this: * The webserver can resolve the SQL server by either IP or FQDN. * The client can resolve the webserver by FQDN (but not reverse) * The SQL server can resolve the webserver by FQDN (but not reverse) – Mikael Grönfelt Aug 16 '10 at 14:13
  • The webserver may be trying to convert the IP from the client to a hostname (example: logging/ACL); same for the SQL server. The (forward) client's lookup business has nothing to do with server responsiveness, the forward lookup from the webserver top the sql server may have influence (but there are far less scenarios where that happens). If static pages work quickly it's probably not the httpd. Try connecting to the sql by hand (from the webserver, and with the same settings). I suspect that may be slow. – Joris Aug 16 '10 at 17:57
  • Also, you can create a very simple php script that connects to the db (again, with the same settings) and does a very simple query. – Joris Aug 16 '10 at 18:00
0

Try to disable the Drupal update status module, with certain firewall configurations it can cause a relatively long timeout. Maybe the MediaWiki issue is distinct, but could also be related with an external lookup.