jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: JMeter Performance evolution : My 2 cents
Date Mon, 28 May 2012 20:05:58 GMT
On Mon, 2012-05-28 at 10:35 +0100, sebb wrote:
> On 27 May 2012 23:02, Oleg Kalnichevski <olegk@apache.org> 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/>



Mime
View raw message