Sorry, but what do you mean by response http “method”?
Heh. There is a request method in the HTTP spec, so maybe somebody is assuming there must be an analogue to that in the response.
The only analogue to that would be the HTTP request status though.
Speaking of which: Is there a way to tell gatling to automatically assume a status code 50x or 40x is always an error? I see scripts always check for status code 200 by hand, but in my experience that check isn’t really meaningful and in fact is commonly done automatically by the tools.
Maybe I’m just spoiled … 
@Floris: see note in documentation: https://github.com/excilys/gatling/wiki/Checks#wiki-status
In master, 304 is also considered a “normal” status.
You can of course (in master) configure a common status check on HttpProtocol, like status.in(Seq(200, 304, XXX))
We can spoil you too
Right. So the tool does the right thing, it’s just the scripts doing very little checking beyond the basic header check.
Maybe I should post a ‘loadtest scripting best practices’ document sometimes. There’s definitely a lot to say that is entirely independent of the tool being used.
Looking at that documentation the definition of the responseTimeInMillis and the latencyInMillis functions actually surprises me. I would expect the former to report the latter number, and the latter to be impossible from within the context of a transaction.
Also, adding a method to get the time spent inside gatling code may be wise, considering that redirects or the new HTML code may cause some overhead. .
@Floris: see note in documentation: https://github.com/excilys/gatling/wiki/Checks#wiki-status
In master, 304 is also considered a “normal” status.
You can of course (in master) configure a common status check on HttpProtocol, like status.in(Seq(200, 304, XXX))
We can spoil you too
Right. So the tool does the right thing, it's just the scripts doing very
little checking beyond the basic header check.Maybe I should post a 'loadtest scripting best practices' document
sometimes. There's definitely a lot to say that is entirely independent of
the tool being used.
+1
Another example is people hammering the same data over and over again,
resulting in benching caches instead of the real application.
Looking at that documentation the definition of the responseTimeInMillis
and the latencyInMillis functions actually surprises me. I would expect the
former to report the latter number, and the latter to be impossible from
within the context of a transaction.
Why?
responseTimeInMillis = last byte received - first byte sent
latencyInMillis = first byte received - last byte sent
How could the latter be impossible?
Also, adding a method to get the time spent inside gatling code may be
wise, considering that redirects or the new HTML code may cause some
overhead.
Will consider.
I’m sure this bit of thread necromancy will raise some eyebrows, but I was digging through my archives and found this conversation that I had not responded to yet so I figured I might as well.
The thing is, “latency” as far as I am aware normally refers to time in transit - how much time is spend in the network part of your response-request roundtrip. Having a graph that purports to measure that is rather confusing and really should not be used for something that is actually measuring quite a lot of the server’s response time. Which, in fact, quite possibly cannot begin responding before the entire request has arrived. Which is why the “responseTime” metric also confuses me since your latency graph more accurately represents how much time the server took to respond than the latency graph does.
Does that, at least, make sense?
Hi Floris,
Long time no seen 
Yes, it agree.
Actually, I’m considering dropping this chart in 2.2.
If someone doesn’t agree, please raise a hand!
Cheers,
Yup. it’s been a while.