On Fri, Jan 23, 2015 at 11:48 PM, Oleg Kalnichevski <ol...@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 <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 > > > 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.
