MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
WebPagetest Forums - Is TTFB indicicator of CPU throttling?

WebPagetest Forums

Full Version: Is TTFB indicicator of CPU throttling?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I was doing a few tests this evening - writing up a case study - will run by you folks when I'm done - and then got this:

http://www.webpagetest.org/result/120426...1/details/

Does this look like CPU throttling (or some other kind of imposed delay)?

Update: here's a less extreme example from the next test:

http://www.webpagetest.org/result/120426...1/details/

Any thoughts on that?

Aside: I know it's not fantastic in general, but FYI this is now well over 60% quicker than original page Smile
It could be CPU throttling or also running out of apache workers to handle the requests (see it happen a lot with keep-alive enabled where the request has to wait for an existing connection to close).

You can look at the apache stats to see the state of the workers (assuming you are running apache). Configuring apache to handle a large number of persistent connections can be a pain.
Hi Patrick,

Thanks for that. The site is running on what I suspect is an overloaded shared hosting box. It's running LiteSpeed. My suggestion is they move the site to a less crowded server - sounds like that could help significantly.

Thanks,
Alastair.
Is there an easy way, from these results, to calculate Render/Full Load delays caused solely by TTFB?
TTFB could also be the amount of time it takes a loop to release itself to create an output. Using the FLUSH(); command could help with that.

Try loading a pure HTML file, meaning nothing is dynamic, and see the difference.
(04-27-2012 06:52 AM)mrPerezMarc Wrote: [ -> ]TTFB could also be the amount of time it takes a loop to release itself to create an output. Using the FLUSH(); command could help with that.

Try loading a pure HTML file, meaning nothing is dynamic, and see the difference.

Wilco. Might try sticking a flush() in the WP theme, maybe after the head (or just after the open body tag). Worth experimenting.

Any other comments/suggestions? Thanks for all the feedback!
The static files all have long TTFB's on them so it's highly unlikely to be a problem where flushing would help. It's very much a server tuning/overload problem (at least that's what it looks like from the outside). Could be the web server or the filesystem but it should be able to turn around static files off of disk in the same amount of time as a socket connect.
Hey Patrick, thanks for coming back to this one. Good point on the static files, obvious now that I think about it.
Reference URL's