0

I have a web application running on an internal network for a client of ours. This question slightly overlaps my other active question about tuning a remote MySQL install. The issue is speed, the app is painfully slow. The app runs beautifully in another environment, so I have ruled out coding.

  • Refreshing a particular page will take minutes (literally) to load.
  • The MySQL server is on a separate box, but its a single 4ms hop from the web server.
  • Its not a slow query, checking the processlist when waiting for the page to load shows no hung queries at all.

What is the next step? Could MySQL still be the problem? Maybe it is retrieving quickly but not returning the data fast enough? Where else can I look?

Thanks very much for any assistance.

Christian
  • 779
  • 1
  • 13
  • 31
  • Can you clarify, when you say "running on an internal network for a client" does that mean the web application server and the database server are running on their network? And that the equivalent system works fine on another network? – Antony Aug 12 '09 at 04:42
  • Sorry, just noticed this. The database server is on their internal network, accessible from outside only via the webserver. And yes, the same setup is working fine on another externally available web & db server. – Christian Aug 27 '09 at 10:14

5 Answers5

1

Can you verify that your DNS is configured correctly and responding fast?

When authenticating a user, MySQL needs to do a reverse DNS lookup to resolve the client IP address to a host name and match it in its mysql.user database.

To check this, you can try something like dig -x <client_ip_address> from your mysql server (or nslookup <client_ip_address> if you run it on Windows).

If that request doesn't respond fast enough, there are plenty of solutions (I can't afford to write all them down right now).

rolaf
  • 558
  • 1
  • 3
  • 8
  • I will have to get their tech dudes to do that as I dont have OS level access to the db server. Good suggestions tho, will give it a go. Thanks! – Christian Aug 27 '09 at 10:15
0

Some ideas:

  • You can check in the slow query log of MySQL
  • Have you tried to run the application with the database in the same web server?
  • You can check the traffic between the two servers with iftop to see if the network is the bottleneck.
hdanniel
  • 4,253
  • 22
  • 25
  • 1. Yep, not many in there and none very slow. 2. Out of the question unfortunately. :( 3. Running iftop now, not sure how to pickup on issues though – Christian Aug 12 '09 at 00:10
  • iftop will tell you how much is the traffic betweeen the two servers. – hdanniel Aug 12 '09 at 13:51
0

A guess that pops to mind is that perhaps the query is being buffered into one result rather than sending data as it's found?

warren
  • 17,829
  • 23
  • 82
  • 134
0

What language is your application developed in? I realise you've said it's not coding related, but can you put some breakpoints or debug points in to find out where it is stalling?

I've done similar things in a language that didn't support remote debugging. Before and after every major function I wrote the time (to the millisecond) into a log file, then when it had finished, checked the log, found the gap in the timestamps, delved into that function, did a similar thing, and eventually found that the delay was caused when calling an authentication service.

If you run into the scenario where all your timestamps are with acceptible limits, then the delay is most likely happening at the web server daemon/service. It could be a misconfigured Apache, or a bad filter in IIS, any number of things...

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • Its written in PHP. I am about to install XDEBUG and profile some of the slow loads to see if it is in fact the application and not the servers / network. – Christian Aug 12 '09 at 00:40
  • It's a good idea. Sometimes I put a profile function in the application to find where is the problem. – hdanniel Aug 12 '09 at 13:53
0

Something that should not be overlooked is the physical network infrastructure. I've seen similar problems before that were eventually traced to a bad network cable. Queries ran fast enough but the network throughput over that cable was unbelievably slow. Replaced the cable and all was well.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108