You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jakarta.apache.org by bu...@apache.org on 2010/07/06 18:39:35 UTC

DO NOT REPLY [Bug 49560] New: wrong "size in bytes" when following redirections

https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

           Summary: wrong "size in bytes" when following redirections
           Product: JMeter
           Version: 2.3.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTTP
        AssignedTo: notifications@jakarta.apache.org
        ReportedBy: dimitris@watchmouse.com


Created an attachment (id=25715)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25715)
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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

Sebb <se...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #3 from Sebb <se...@apache.org> 2010-07-07 19:59:04 EDT ---
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!

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

--- Comment #6 from Dimitris Balaouras <di...@watchmouse.com> 2010-07-08 11:41:41 EDT ---
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!

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

Sebb <se...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Sebb <se...@apache.org> 2010-07-08 05:09:59 EDT ---
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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

Sebb <se...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #2 from Sebb <se...@apache.org> 2010-07-07 11:14:58 EDT ---
Just noticed - google's redirect response includes text, so that can be used
for testing.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

--- Comment #4 from Dimitris Balaouras <di...@watchmouse.com> 2010-07-08 02:06:15 EDT ---
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!

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org


DO NOT REPLY [Bug 49560] wrong "size in bytes" when following redirections

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49560

Sebb <se...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #1 from Sebb <se...@apache.org> 2010-07-07 11:11:52 EDT ---
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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org