Get and measure the number of requests per page

[dmonllao]

Would be useful to add a new measure variable to compare the number of requests per page because there are changes in how we join JS files for example, this means that:

• We set the test plan to download also all the included JS, CSS... There is a setting for that (http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request) and * * We update the recorder to get that data from the thread results and add it to the runs PHP file
• We update the results output to add that var

[stronk7]

two questions:

1. is jmeter able to simulate a real browser by caching locally like them? And to use modified-since and etags headers like a real browser? Or it always, simply, requests everything? Differences can be noticeable.

2. if the client, when requesting any image/css/js... is using techniques like the ones commented in 1)... can receive a simple response from the server saying "has not changed, continue using your locally cached copy" or, also, of course, the complete response. IMO if we could "account" those 2 types of responses separately, the better.

If 1) is not possible... then I bet 2) has no sense (jmeter always will receive the complete response) and the separation won't happen, I assume. Pitty coz results can be really different (we are using modified-since and etags way more in 2.6 than in 2.5 for example... and we'll be missing that).

Ciao :-)

[stronk7]

also... one more question...

3. How does that affect to timings for the main page? I hope they continue being the same and jmeter does not sum other resources times to the main one. That would lead to wrong numbers. Sure it does not. Just to confirm it.

[dmonllao]

Hi,

1. Yes, http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cache_Manager
2. I have never used the cache manager, reading the above doc: "If the request is a GET request, and the timestamp is in the future, then the sampler returns immediately, without requesting the URL from the remote server" we would need to check if "the sampler returns immediately" implies that it is counted as an obtained resource. It makes sense if we are interested only in the number of files requested rather than in the time it takes (a catch'em all I mean)
3. The current timeused comes from the moodle page output

[stronk7]

About 2) yes I agree the interesting stat there is the "number of files requested". Just was trying to expose that it would be interesting to have separately:

1. number of files that were served completely.
2. number of files that did not need to be served completely (because of browser caching and or modified-since/etag header response).

Imagine that, right now... 2.5, for the mod/xx/yy page requests 50 files (and all them are not cached ever). And imagine that 2.6, for the same page requests 100 files (all them cached in the browser). If we just account files... it will be considered that 2.6 is worse, when really it's far better (coz the 100 files are cached and not-modified/etags or expires/cache-control are preventing it to happen).

So really, if we cannot separate 1) and 2)... at least I'd love to see that 2) requests are not accounted at all. So only really served pages are accounted (and we'll be able to compare them). And then we'll can compare them ok (non cached vs non cached).

Also, we could have that metric disabled by default (so developers and others running comparisons can do it quickly) and only enable them in our servers. Or the opposite: always enabled, but with some setting to disable them. Any of those options only needed if moving to "complete requests" causes the test plan to become loooonger, of course. If not, I'd vote to have it enabled always (still a disable setting may have sense, for your consideration).

Ciao :-)