On Fri, 2015-01-23 at 23:10 +0100, Philippe Mouawad wrote:
> On Fri, Jan 23, 2015 at 10:00 PM, Oleg Kalnichevski <ol...@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 <ol...@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



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to