[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jmeter-user
Subject:    Re: JMetere JDBC Test Confusing Result
From:       sebb <sebbaz () gmail ! com>
Date:       2010-06-30 19:34:31
Message-ID: AANLkTiniIWn6PifZvcIZaTXkapR9RKMXj5zU88ZOEtS2 () mail ! gmail ! com
[Download RAW message or body]

On 30/06/2010, jz <jehanzeb.qayyum@gmail.com> wrote:
> This is exactly what i did.
>
>  I wanted to open all 10 connections before i do actual testing.
>
>  For this i added Thread Group 1 with 10 threads and a dummy select
>  statement.

As I already explained, unless you switch off pooling, there is no
guarantee that the select will exercise all the connections. And if
you do switch off pooling, it won't help either, because the second
thread group will use different threads.

>  Now thread group 2 which has 100 threads, starts with a delay of
>  5 seconds. In those 5 seconds Thread Group 1 has opened all connections and
>  thread group 2 uses those opened connections only.

No, that won't happen, for the reasons stated above.

Furthermore, if you are using 100 threads with a pool max of 10,
JMeter will only be able to issue at most 10 concurrent SQL requests.

And if pool max = 100 in Thread Group 2, then at least 90 connections
will need to be initiated, possibly more.

>  Regards,
>  Jehanzeb Qayyum
>
>
>
>
>
>  On Wed, Jun 30, 2010 at 3:45 PM, sebb <sebbaz@gmail.com> wrote:
>
>  > On 30/06/2010, sebb <sebbaz@gmail.com> wrote:
>  > > On 30/06/2010, jz <jehanzeb.qayyum@gmail.com> wrote:
>  > >
>  > > > Guys its a web applications. And connection pooling will be provided by
>  > >  >  container. I wanted to test only the time taken by query/stored
>  > procedure,
>  > >  >  not the time of spent in opening connection.
>  > >
>  > >
>  > > So don't use connection pooling in JMeter.
>  > >
>  > >  If you think about it, there will still be the same number of
>  > >  connections generated.
>  > >
>  > >  Either 10 in a pool, or 1 each in 10 threads.
>  > >
>  > >  Also, the connections are opened before the samplers run anyway.
>  >
>  > Actually, I'm not sure that is true; it's possible that the connection
>  > is opened on first use.
>  >
>  > In which case, just add a dummy select statement at the start of the test.
>  >
>  > Note that this may or may not work if you are using connection
>  > pooling, because the first samples in each thread may share a
>  > connection. In which case the first use (and connection open) may
>  > occur in the middle of testing.
>  >
>  > For repeatability, don't use pooling.
>  >
>  > >
>  > >  >  Regards,
>  > >  >  Jehanzeb Qayyum
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  >  On Wed, Jun 30, 2010 at 3:19 PM, sebb <sebbaz@gmail.com> wrote:
>  > >  >
>  > >  >  > On 30/06/2010, Sudip Kumar Bhattacharya <
>  > skb.subscriptions@gmail.com>
>  > >  >  > wrote:
>  > >  >  > > If it is a j2ee web application, app server wud be doing the
>  > connection
>  > >  >  > pooling.
>  > >  >  >
>  > >  >  > Yes, agreed.
>  > >  >  >
>  > >  >  > >  If it is a desktop app running from multiple terminals then
>  > connection
>  > >  >  > pooling won't be there across multiple users.
>  > >  >  >
>  > >  >  > Yes, agreed.
>  > >  >  >
>  > >  >  > >  I hope you are testing for a web application.
>  > >  >  >
>  > >  >  > If the OP wants to emulate the behaviour of a web application, then
>  > >  >  > they need to test using the pooling code actually used by the
>  > >  >  > applicaton, not the pooling code which happens to be used by
>  > JMeter.
>  > >  >  >
>  > >  >  > Note that the JMeter pooling implementation cannot be changed
>  > (except
>  > >  >  > by rewriting the code!).
>  > >  >  >
>  > >  >  > Alternatively, work out how many independent connections are
>  > created
>  > >  >  > by the web application, and use that many JMeter threads.
>  > >  >  >
>  > >  >
>  > >  > >
>  > ---------------------------------------------------------------------
>  > >  >  > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>  > >  >  > For additional commands, e-mail:
>  > jmeter-user-help@jakarta.apache.org
>  > >  >  >
>  > >  >  >
>  > >  >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>  > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>  >
>  >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]