>I noticed that around 10 jmeter request threads would
>generate over 75 tomcat http protocol processor threads,
>and looking at the source indicates that the reason is that
>org.apache.jmeter.protocol.http.sampler.HTTPSampler does
>not call disconnect() on the HttpURLConnection itself, but
>only on its input and output streams (which is not the same
>thing). So Tomcat's processor threads hang around until the
>socket times out.
Interesting. The 'keepalive timeout' should be a configurable
parameter. The problem here is that JMeter is relying on the
timeout.
>I'm guessing this is a bug. It seems to me that
>conn.disconnect() should be called in a finally clause at
>the end of HTTPSampler.sample() (and I guess the same method
>in HTTPSamplerFull). At least this made the problem go away
>for me.
A well-behaved client is supposed to set 'Connection: keepalive'
on each request, and then either set 'Connection: close' (HTTP 1.1)
or no 'Connection: keepalive' header (HTTP 1.0) for the last request.
Calling disconnect() may let the HTTPD process know that the
connection can be terminated. As an option, it would be nice to be
able to request HTTP 1.0 (of course, HTTP 1.1 should be the default),
as certain HTTP 1.1 implementations are known to be flawed (Java,
for example) and therefore require an HTTP 1.0 response:
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
For benchmarking purposes, I would guess that HTTPSampler should
always set 'Connection: close' (effectively HTTP 1.0) and that
HTTPSamplerFull should follow the keep-alive protocol.
Any other thoughts ?
Regards
Martin Ramshaw, Consultant
http://pages.sprint.ca/mramshaw/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
