On Mon, 2012-05-28 at 10:35 +0100, sebb wrote: > On 27 May 2012 23:02, Oleg Kalnichevski <[email protected]> wrote: > > On Sun, 2012-05-27 at 23:08 +0200, Philippe Mouawad wrote: > >> Hello Oleg,milamber, > >> Thanks for your investigations. > >> > >> Oleg, Regarding connectionmanager, do you think it's better to use one > >> connmgr for all vus ? > >> Today we use one per VU but we reuse httpclient instance when downloading > >> embedded résources in parallèl mode. > >> What would be the compromise ? > >> > >> Thanks > >> Regards > >> Philippe > >> > > > > Hi Philippe > > > > It really depends on what you define as 'better' and what your > > objectives are. If your goal is to emulate load generated by 20 browser > > instances as realistic as possible you should be using a separate > > connection manager per virtual user. (In this case, though, you should > > be using a pooling connection configured to allow up to 2 simultaneous > > connections to the same host instead of a basic connection manager with > > a single connection). > > Why would 2 connections be needed? >
Commons browsers usually allocate 2 concurrent connections per host. I think a pooling connection manager with two connection per route limit would be a more realistic simulation of a browser. Naturally this would also require two worker threads per virtual user. > > If your goal is to generate as much load as > > possible using 20 virtual users you should be using a pooling connection > > manager configured to allow up to 20 connections to the same host shared > > by all virtual users. > > If 2 connections are needed for the first case, wouldn't we need some > spare connections in this case too? > If one virtual user is represented by one thread there is no point having more connections than the total number of worker threads. Oleg > > You should also take into account that Java standard HttpUrlConnection > > is not well suited for the former scenario as it always uses one global > > connection pool for all its instances. This is likely to be the reason > > why the HttpUrlConnection based sampler tends to yield the highest > > request per second in the performance tests. > > JMeter has historically tried to ensure each VU behaves completely > independently. > I don't think we should change that by default. > > However, it might be worth considering optionally using a shared > connection pool. > > <snip/>
