+1
I haven't used HTTPClient in a while, but the default java HttpConnection is a bit
retarded. Given the way I use JMeter, I don't think having "keep-alive" always on is a
problem. For me atleast, having it on produces better results. this is based on the
benchmarks I ran with remy using Jmeter and Apache AB.
peter
Sebastian Bazley <[EMAIL PROTECTED]> wrote:
Jordi Salvat i Alabart wrote:
> Hi.
>
> One of the important proposed changes to JMeter was to switch from the
> java.net HTTP client to the Apache Jakarta Commons HTTPClient.
+1
>
> I've been reading through HttpClient's docs, and the changes are not
> trivial.
We might be able to use the HttpURLConnection wrapper with the existing HTTPSampler
code,
but I don't think that gives any advantages.
>
> To start with, the equivalents of our cookie manager and
> authentication manager (including proxy authentication) are part of
> one single object, the HttpState. I'm not so sure we can keep their
> functionality separate and still have reasonably clean and efficient
> code.
>
> Next, there's really no control over usage of keep-alive, as far as I
> can see: it will always try to use it. I'm not sure this is really a
> problem, since it matches the behaviour of most clients. And you can
> choose which protocol level to use: HTTP 1.0 or 1.1, which is
> obviously an advantage.
Although one can select to use keep-alive at present, it does not work as intended,
because there is no control over connection re-use.
So effectively this would mean changing from never using keep-alive to always using
keep-alive.
But I don't think this is a problem.
>
> There's other small quirks. For example: I don't see support for our
> "Includes Equals" features of HTTP Request Parameters. This means we
> would not be able to shift responsibility for the generation of the
> query string to the HttpClient. Unless, of course, we can influence
> the Commons team to add that functionality for us. [Q: do we really
> need to control that per-parameter? Wouldn't a global setting be
> enough? Mike: you implemented this -- can you remember the rationale
> behind the requirement?]
>
> The following funcionalities are poorly implemented in JMeter and
> would most likely benefit from moving to HttpClient:
> - Multipart POST requests
> - Cookie handling.
> - Authentication (support for non-Basic auth, for example).
> - Connection pooling in keep-alive mode.
> - Unit testing: HttpClient comes with a test webapp, that we could use
> to write equivalent JMeter tests.
>
> IMO, the last two above are enough to justify the change to
> HttpClient.
There is no control over what happens with connections when using the standard
HttpUrlConnection class, and its API is not
particularly suitable for connection re-use - for me, that is reason enough to move
away from the default.
> The following functionalities (of those where I expected HttpClient to
> help) will not improve at all, and we will still need to handle them
> ourselves:
> - Request parameter encoding
> - Follow redirects
As far as I can tell, it does handle some redirects - but it does not handle
cross-site redirects yet.
> - byte[]-to-String translation of responses
> - Cache management (not yet there in JMeter)
>
> My proposal is to start by creating completely new components ("New
> HTTP Sampler", e.g.). When we will be sure they work well, we will
> deprecate the old components, possibly removing them from the menus.
+1
> Eventually we should be able to remove them from the codebase (maybe
> in a 2.0 release...). If we're careful enough, we could even manage
> to get most config elements and pre-processors to work for both...
+1
>
> Opinions?
Thanks for doing all the investigation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
