HTTP server: lighttpd/1.4.28
PHP version: 5.2.17
XCache Enabled
MySQL version: 5.1.39-log
Application: Invision Power Board v1.3.1 Final
I notice there is a 250ms gap between initial connection and TTFB. Is it because the Start Offset is 0.326s ? If so, is there something I can do to reduce this start offset time? I am on a 300MB VPS with very light CPU load (0.05~0.15) on a 100Mbps line. Where should I start looking? This has been bugging me for a long time, I just feel my site isn’t loading as fast as it should be. I even went through the code line by line.
I think you’re in good shape. That gap is driven by the actual test machine and it’s performance (disk, antivirus, etc). Try again from Dulles where the testers are running on SSD’s and you’ll see that behaving much better.
Thanks pmeenan for the quick response! The results from Dulles really are much better and similar to the tests I’ve seen here. The connections are much more continuous.
The application I use seem to have a loading problem when a topic/thread gets big (>5000 replies) It would hang for 5 or 6 seconds before it does anything. Then within one second, everything is displayed. I’ve been benchmarking and it seems all subsequent pageloads are super fast. Looking at the waterfall, it seems the site is hanging after the Initial Connection for 5 seconds. I’ve already profiled the PHP codes and MySQL queries. All MySQL Queries only took roughly 200ms to complete and the PHP microtime only took about 400ms to complete the whole page.
Could it be a server configuration that caused the huge delay between Initial Connection and TTFB? I’ve been trying to figure out this problem for several months and to no avail. Here’s something for reference: http://www.webpagetest.org/result/111207_A5_2E9DE/ This is a test on a topic with only 50 replies. And it seems to load fairly quickly even on first view.
All indications seem to point to threads with large amount of replies as the culprit, but I just don’t know where to start. I even tried stepping through the code line by line to see if there’s anything that seem to put the thread in a big loop, but I didn’t find anything significant enough to cause such a delay.
How did you do the profiling? It’s possible that by the time you instrumented it the database queries were in the mysql memory cache already and they returned a lot faster than they would on a cold hit. If you can, I’d recommend enabling slow query logging and then look at the logs.
Web server configuration issues would generally show up regardless of the size of the thread. It’s going to be in the actual query or the code that parses it (my bet is on the query itself).
You can give New Relic a shot (it has a free level but for the first 14 days you actually get the full pro product for free to try it out). It will profile the php and database calls and tell you where the time is going.
Oh my goodness, thank you so much pmeenan. I signed up at New Relic and checked out their service. I figured out what was causing the lag and fixed it. Now big threads with 5000+ replies load instantly! You are a life saver!