hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: httpClient.getConnectionManager() performance with HTTP only
Date Fri, 23 Jan 2015 22:57:13 GMT
On Fri, Jan 23, 2015 at 11:48 PM, Oleg Kalnichevski <olegk@apache.org>
wrote:

> On Fri, 2015-01-23 at 23:10 +0100, Philippe Mouawad wrote:
> > On Fri, Jan 23, 2015 at 10:00 PM, Oleg Kalnichevski <olegk@apache.org>
> > wrote:
> >
> > > On Fri, 2015-01-23 at 20:42 +0100, Philippe Mouawad wrote:
> > > > On Fri, Jan 23, 2015 at 6:09 PM, Oleg Kalnichevski <olegk@apache.org
> >
> > > wrote:
> > >
> > > ...
> > >
> > > > > >
> > > > > > > Please note that if JMeter needs to simulate several physical
> users
> > > > > > > having a separate connection pool per distinct user may
be the
> > > easiest
> > > > > > > and the most representative strategy.
> > > > > > >
> > > > > >
> > > > > > What is the object to use if it's not 1 HttpClient per user
as
> we do
> > > > > today
> > > > > > ?
> > > > > >
> > > > > > PoolingHttpClientConnectionManager does not seem to be the one,
> as if
> > > > > > it's shared among threads, how could we reset it only for 1
user
> ?
> > > > > >
> > > > >
> > > > > You should continue using one HttpClient instance per distinct user
> > > > > either with a pooling or basic connection manager. The only thing
> you
> > > > > might want to customize is changing SSL context initialization from
> > > > > eager to lazy.
> > > > >
> > > > >
> > > > Does it means we are stuck with 1 HttpClient instance per distinct
> user ?
> > > >
> > >
> > > What do you mean by that? You do not have to use one HttpClient
> instance
> > > per distinct user, but it makes things easier if you really need to
> > > ensure that one user thread cannot re-use connections created by
> another
> > > user thread.
> > >
> > >
> > The requirement is related to Mutual SSL authentication feature (mainly
> > auth by certificate but also tests that want to put pressure on HTTPS by
> > replaying SSL Handshake).
> > To implement this we need to  Control reuse of cached SSL Context, see:
> > - https.use.cached.ssl.context property
> >
> > Currently in JMeter, as we have 1 HttpClient per user, we are able to
> call
> > without impacting other user:
> >
> >    - httpClient.getConnectionManager().closeIdleConnections(1,
> >    TimeUnit.MICROSECONDS);
> >
> > My understanding of your answer was that if we switch to a shared
> > HttpClient instance doing this would have side effects on other users.
> >
> > So I concluded we needed to stick to 1 HttpClient per Thread/User.
> >
> > Did I misunderstand ?
> >
> > If I did, then I still don't see how we can reset SSL Context for 1 user
> if
> > we have 1 HttpClient per thread/User.
> >
>
> What is your main _design_ objective here? Do you want to generate
> maximum load in terms of requests per second across multiple user
> threads or do you want user threads to represent a single user as
> realistically as possible? If former you should be using one pool of
> connections for all threads / users, if the latter you should be using
> one pool per thread / user.
>
> Oleg
>
>
> IMHO Design objecitve is being realistic while having the best possible
performance.
So now answer is clear :-), seems we willl stick to 1 HttpClient per user.

Thanks a lot for your time and precious help Oleg !!!




-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message