You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2018/01/28 13:25:33 UTC
[Bug 62045] timing difference for large (?) requests
https://bz.apache.org/bugzilla/show_bug.cgi?id=62045
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
OS| |All
Status|NEW |NEEDINFO
--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello,
Does you file contain an uploaded file ?
What does the response look like ? Would it be possible to attach the fiddler
response ?
Thank you
On Thu, Jan 25, 2018 at 5:21 PM, Alexander Podelko <ap...@yahoo.com> wrote:
Hi,
1. For example, in Fiddler - as specified below.
2. Oracle Application Testing Suite. No rendering, it is recording on
protocol level.
3. 3.3
4. Only that in real browser / Fiddler I see different time - and that
pretty much matching what I see in OATS.
I understand that here we may have interesting subtle issues - but I'd like
to understand what they are as difference is quite noticeable. Clearly timing
issues are very difficult to investigate - but this looks like may be a good
example to check if there is any issue with that.
I will be happy to do whatever further measurement is needed.
Thanks,
Alex
On Thursday, January 25, 2018, 11:00:40 AM EST, Philippe Mouawad
<ph...@gmail.com> wrote:
Hello Alexander,
Could you give more details on:
1/ How you measure response time in real product ? Is it a browser ?
2/ In the other tool you use ? what is used ? does it take into account
Rendering ?
3/ which version of JMeter are you using ?
4/ IMU, JMeter measures shorter response time, so what makes you think it's
the other tool that is correct ?
JMeter only computes time to receive last byte not full rendering time, but
if your tool has some Rendering that takes time it would not be measured
and would explain the difference.
Unless you provide more details , I am afraid it is hard to help.
Regards
--
You are receiving this mail because:
You are the assignee for the bug.