75 seconds is nothing! Why, when I was young, we’d count ourselves lucky if a web server responded within the day…
In its defence, I’d been doing other things before requesting again .. enough time for some of it to go into swap. But man, 75 seconds!
December 12th, 2007 at 8:24 pm
Ridiculous. So the numbers in brackets are seconds, right?
About 1 second to “SHOW FIELDS FROM …”?
Over 1 second to “SELECT * FROM ‘users’ WHERE ‘users’.'id’ = 1″?
Your interface_strings query taking nearly 20 seconds?
Oddly enough, the monster query at the end takes just over 0.07 seconds.
I think you should whip out some profiling tools and figure out where the hell the time is being spent; I’m sure that it’s not MySQL itself (I’ll bet if you run the same queries by hand they’ll be next to instantaneous), but something that Rails wraps around it. These times are so bad that they make one suspect a configuration problem or something external.
Will be very interested to hear the results if you delve any deeper into this.
December 13th, 2007 at 1:22 pm
Yes, the numbers are in seconds. But it’s not just SQL activity, the numbers also include Rails’ processing - obviously that’s not shown in the log though.
But, as I said it’s a bit unfair - it was partially swapped out and also running in developer mode. This was anomalous, usually it’s *much* faster and in production mode it’s quite acceptable. I just thought it was amusing as I’ve never actually seen a local dynamic page take that long to serve, ever.
I think the reason the “massive” query at the end takes so little time is that MySQL, or the ruby wrapper framework as you suggested, is out of swap by then!
The picture from production mode is far less interesting so I’ll copy the relevant text:
As you can see, totally acceptable (for rails anyway) in production mode. Weirdly, it’s reporting DB as taking zero time, to 6 significant digits - it does this consistently, although I somehow doubt MySQL is really responding in under a hundred thousandth of a second ..