https://bz.apache.org/bugzilla/show_bug.cgi?id=66248
--- Comment #7 from John <[email protected]> --- When this is for testing for services used by a browser I agree (mostly). I'm testing services which are use from another service. So no browser involved. The calling service is using connection pooling, so normally everything is already setup. So I'm only interested in the server response times (incl ssl handshake). Not in the client setup (before ssl handshake). The time for the setup will also be specific for which client is used. When using Jmeter with openjdk 18 of Java 1.8 I see already a big difference in setup time. So it will never be representative if there are different clients. Also for browsers. So better to leave it out :-) Doing a lot of requests, this will not be a big problem. With load testing you will gradually increase the number of parallel requests and wait until this is stable. You will use the response times in the stable period. I don't this can be handled by jmeter, I'm more a Loadrunner guy :-). So b can be useful for everyone. Also a could work. C would only work if the setup will be excluded from the first request response time. Making it more specific: I have 2 webservers with a loadbalancer in front of it. I do 1 request on the LB, 1 request on server 1 and 1 on server 2. This are are different "urls". So I don't repeat a request. Now 1 of the 3 shows a big difference in response time. So it is 1 iteration with 3 different requests. So then a won't work I think. Except when making an iteration of 2 for the first destination. Maybe just a checkbox on the request with the choice the exclude it from the stats (including jtl). Then I have to add a extra request as sort of dummy request. -- You are receiving this mail because: You are the assignee for the bug.
