Created attachment 25715 [details] patch for correcting the parent's "size in bytes" when following redirections Using an HttpRequest Sampler on a url that redirects but also returns some body message next to the 30x headers, gives wrong size in bytes. More precise, the "parent" http sample gets a value in "size in bytes" equal to 2x[initial request] + [size of the rest subrequests] This issue has been addressed quite some time ago (http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg25592.html) by one of my colleagues (Mr. Pieter Ennes, WatchMouse.com) but it has not been fixed yet (checked in version 2.3.4). We have located the root cause of this problem and it resides in the class src/core/org/apache/jmeter/samplers/SampleResult.java. The constructor "SampleResult(SampleResult res)", clones the initial result to a "Parent" result object and sets it as the child of the Parent. During this cloning the following piece of code causes some trouble: <code> public SampleResult(SampleResult res) { ... setResponseData(res.getResponseData()); ... ... addSubResult(res); // this will add res.getTime() to getTime(). ... </code> The invocation of addSubResult in the code above does this: setBytes(getBytes() + subResult.getBytes()); which sets the bytes of the parent to 2x[size of initial subresult]. Of course that is if the initial request has some body message and not just the headers with the 30x response. Although it's common that 30x response have no message body, it is not always the case. And I think JMeter should give fine figures at all times. In the patch attached to this report, I have replaced this invocation with this code: <code> String tn = getThreadName(); if (tn.length()==0) { tn=Thread.currentThread().getName();//TODO do this more efficiently this.setThreadName(tn); } res.setThreadName(tn); if (subResults == null) { subResults = new ArrayList<SampleResult>(); } subResults.add(res); // Extend the time to the end of the added sample setEndTime(res.getEndTime()); // Include the byte count for the added sample setBytes(res.getBytes()); res.setParent(this); </code> which is the code of the function addSubResult but stripping out the "getBytes()" part. This patch has been tested over several scripts and gave fine results. Please give it a look as you might find it useful; if so, please add it in a next release.
There are two different usages for the constructor SampleResult(SampleResult res) - following redirects - downloading page resources I agree it seems wrong the way the sub-results are added currently, but I'm not yet sure of the best solution. Possibly the constructor should only create a clone of itself, and not add itself as a sub-result. The calling code would need to be changed accordingly, but would be easier to understand. Other samplers that call addSubResult() do so directly; it only seems to be the HTTP samplers that use the copy constructor. Is there a public URL that could be used to test against?
Just noticed - google's redirect response includes text, so that can be used for testing.
I've reworked the copy constructor to do a real copy and fixed the bytes problem (I hope!) In the process, the latency was also fixed for redirects. URL: http://svn.apache.org/viewvc?rev=961539&view=rev Log: Bug 49560 - wrong "size in bytes" when following redirections Modified: jakarta/jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java jakarta/jmeter/trunk/xdocs/changes.xml jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml The code will be in nightlies after r961539 - if possible, please could you try one and report back? Thanks!
Hi Sebb, I've just svn up-ed my working copy to the HEAD revision and it looks nice! Many thanks for this quick fix! I have once more question though; I am wondering why did you set the latency of the parent to the latency of the first child? Shouldn't you count the overhead of the redirections in that figure? I would think that the latency of the parent element is from START until the first byte of the FINAL (landing) page. Thanks again!
In the case of "download embedded", latency should definitely only be time to first response of parent page, but then the parent page is the first to be downloaded anyway. In the case of redirects, it's not so clear-cut, but I still think it makes sense to stick with the intial redirect latency, as that is how quickly the server has responded to the original request.
hmm..indeed it's not so clear in case of redirects.. Maybe an "overall_latency" figure would make sense here. Anyways, thanks again for the fix!
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2383