On 28 May 2012 21:05, Oleg Kalnichevski <[email protected]> wrote: > 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.
OK, understood. [JMeter uses a single thread for the initial sample, and optionally uses multiple threads for any embedded resources found.] >> > 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/> > >
