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