[Evo] Diagnosing page load delays?

I am trying to figure out why I am getting 4-8 second "time to first byte" readings on a website I’m working on ("time to first byte" as reported by webpagetest.org). Initially I thought it was a gallery and javascript issue. But after moving javascript to the bottom of a page and then commenting out the entire gallery call, I still see high times reported periodically.

The page being called is set to cached (and the snippet call is uncached, when included). htaccess directives are set for DEFLATE and content-expires. There are no php errors that I see being generated. I’ve got the same site on two different servers and am seeing the same thing happening. So I’m thinking I have something misconfigured or not optimally configured or just not configured. Or I’m just missing something entirely ...

Can anyone suggest how I can go about figuring out where the delay is taking place? How can I throw MODX (Evo) into some sort of debug mode that will show were time is geing eaten up?

Advice would be welcome,
Matt

Okay, I think I’ve tracked this down. Brute force won out over elegance in the form of microtime(true) calls littered throughout the code, finally narrowing down the culprit - which was a config setting in the gallery call.

The first problem I had was a misconception. I believed that the "time to first byte" was essentially how long it took to get to the webpage. In the context of MODX (Evo) , it seems more to be a measure of "how long it takes to put the page together." Digging through the gallery code (Easy2Gallery) I found that the images for the gallery were being generated every time a call was made. I somehow thought those would have been created and cached. In any case, when I set ss_img_src to "original" I picked up multiple-seconds on the page assembly time.

This doesn’t explain why I was seeing long times to load when (I thought) the gallery call was commented out. But I also saw that I had a Ditto call that was being called "cached" on this cacheable page. And I thought that was a no-no. So maybe that came into play as well.

FWIW ...
Matt

Quote from: mconsidine at Apr 01, 2011, 12:23 PM

This doesn’t explain why I was seeing long times to load when (I thought) the gallery call was commented out.

From experience, using html comment tags around a snippet will not prevent the snippet code from being executed. It will only hide the output

Remember, HTML is for the browser to parse and process. MODx does not parse or otherwise process HTML, it only looks for its own tags. Well, mostly, anyway; it does look for </head> tags when inserting javascript or css when you use the regClientStartupScript() function and its siblings. Certainly, though, HTML comments have no effect on the MODx parser at all (there are a few snippets and plugins that parse for HTML comment tags for their own purposes, but that’s another matter).

Thanks for the replies. Usually when I comment out a chunk or snippet I remember to insert spaces to bust their recognition by the MODX parser. I thought I did that this time, but perhaps not. Or perhaps it was something goofy with the webpagetest site (their reported times seemed - at times - to be longer than what I was experiencing).

It’s a moot point now though, as subsequent tests have showed 1 sec or so times, having put in place the gallery fix (see the E2G PL thread).

Matt

EDIT : PS I mean that *my* observation is a moot point. Not the replies of others