You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by jz <je...@gmail.com> on 2010/06/30 07:42:03 UTC
JMetere JDBC Test Confusing Result
Hi,
I am running JMeter JDBC test. I am getting confusing results which vary
with no. of threads and no. of connection in pool
Query: select sysdate from dual
Test Case 1:
no. of threads: 10
no. of connetcions: 1
Avg Sample Time is 5 ms
Now i increase no. of connections to 2, thinking that it would decrease
sample times. But now avg. sample time moves to 200 ms. I have noticed that
increasing no. of connections while keeping no. of threads constant
increases sample times. Please can someone explain this phenomenon?
Thanks
Regards,
Jehanzeb Qayyum
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
To give you more idea. Here are current settings:
Test Plan
-----JDBC Connection Config
-----Thread Group 1
----------JDBC Request 1
-----Thread Group 2
----------JDBC Request 2
-----View Result in Table
Here both JDBC Requests are using same connection pool.
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 3:42 PM, jz <je...@gmail.com> wrote:
> Results do not agree with your proposition.
> For Thread group 1 average sample time was 2000 ms
> and for thread group 2 average sample time 250 ms
>
>
>
>
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 3:31 PM, sebb <se...@gmail.com> wrote:
>
>> On 30/06/2010, jz <je...@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.
>>
>> > Regards,
>> > Jehanzeb Qayyum
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Jun 30, 2010 at 3:19 PM, sebb <se...@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
>>
>>
>
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
Results do not agree with your proposition.
For Thread group 1 average sample time was 2000 ms
and for thread group 2 average sample time 250 ms
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 3:31 PM, sebb <se...@gmail.com> wrote:
> On 30/06/2010, jz <je...@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.
>
> > Regards,
> > Jehanzeb Qayyum
> >
> >
> >
> >
> >
> > On Wed, Jun 30, 2010 at 3:19 PM, sebb <se...@gmail.com> wrote:
> >
> > > On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
>
>
Re: JMetere JDBC Test Confusing Result
Posted by Sudip Kumar Bhattacharya <sk...@gmail.com>.
You may have to keep the number of threads limited in that case, otherwise it would choke your db with too many connections and give incorrect results.
Keeping number of threads equal to pool count is a good idea in this case, and avoid jmeter connection pool.
Sent on my BlackBerry® from Vodafone
-----Original Message-----
From: sebb <se...@gmail.com>
Date: Wed, 30 Jun 2010 11:31:11
To: JMeter Users List<jm...@jakarta.apache.org>
Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
Subject: Re: JMetere JDBC Test Confusing Result
On 30/06/2010, jz <je...@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.
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 3:19 PM, sebb <se...@gmail.com> wrote:
>
> > On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
On 30/06/2010, jz <je...@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 <se...@gmail.com> wrote:
>
> > On 30/06/2010, sebb <se...@gmail.com> wrote:
> > > On 30/06/2010, jz <je...@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 <se...@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
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
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. 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.
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 3:45 PM, sebb <se...@gmail.com> wrote:
> On 30/06/2010, sebb <se...@gmail.com> wrote:
> > On 30/06/2010, jz <je...@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 <se...@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
>
>
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
On 30/06/2010, sebb <se...@gmail.com> wrote:
> On 30/06/2010, jz <je...@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 <se...@gmail.com> wrote:
> >
> > > On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
On 30/06/2010, jz <je...@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.
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 3:19 PM, sebb <se...@gmail.com> wrote:
>
> > On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
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.
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 3:19 PM, sebb <se...@gmail.com> wrote:
> On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
>
>
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
On 30/06/2010, Sudip Kumar Bhattacharya <sk...@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
Re: JMetere JDBC Test Confusing Result
Posted by Sudip Kumar Bhattacharya <sk...@gmail.com>.
If it is a j2ee web application, app server wud be doing the connection pooling.
If it is a desktop app running from multiple terminals then connection pooling won't be there across multiple users.
I hope you are testing for a web application.
Sent on my BlackBerry® from Vodafone
-----Original Message-----
From: sebb <se...@gmail.com>
Date: Wed, 30 Jun 2010 11:01:58
To: JMeter Users List<jm...@jakarta.apache.org>
Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
Subject: Re: JMetere JDBC Test Confusing Result
The target application is irrelevant.
What is important is what use-case you are trying to simulate.
If you are trying to emulate multiple independent users connecting to
your application, you should not be using connection pooling in
JMeter.
On 30/06/2010, jz <je...@gmail.com> wrote:
> Connections are pooled between threads. I am talking about a j2ee
> application.
>
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 2:27 PM, sebb <se...@gmail.com> wrote:
>
> > On 30/06/2010, jz <je...@gmail.com> wrote:
> > > Thanks
> > >
> > > Yes i am also thinking on same lines. It must be connection opening
> > > overhead. e.g. if i do this
> > >
> > > no. of threads: 10
> > > no. of connections: 10
> >
> > You should use "Max Number of Connections" = 0 otherwise connections
> > are pooled between threads, which would not happen with independent
> > users in real life.
> >
> > > ramp-up: 0 sec
> > >
> > > So these threads will open all connections. Now when i re-run the above
> > > test, will the physical connections be opened again or taken from pool
> > of
> > > previous run?
> >
> > Connections are not kept between runs.
> >
> > > I will also share, results of your idea.
> > >
> > > Regards,
> > > Jehanzeb Qayyum
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Jun 30, 2010 at 10:52 AM, Sudip Kumar Bhattacharya <
> > > skb.subscriptions@gmail.com> wrote:
> > >
> > > > Can it be related to the overhead of creating the extra connection
> > objects
> > > > and getting the connection to the db?
> > > > You can take the connection creation overhead by running your query in
> > a
> > > > loop of say hundred iteration.
> > > > Then if you average out by taking total time /total iterations, you
> > may get
> > > > the expected output.
> > > > Sent on my BlackBerry® from Vodafone
> > > >
> > > > -----Original Message-----
> > > > From: jz <je...@gmail.com>
> > > > Date: Wed, 30 Jun 2010 10:42:03
> > > > To: <jm...@jakarta.apache.org>
> > > > Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
> > > > Subject: JMetere JDBC Test Confusing Result
> > > >
> > > > Hi,
> > > >
> > > > I am running JMeter JDBC test. I am getting confusing results which
> > vary
> > > > with no. of threads and no. of connection in pool
> > > >
> > > > Query: select sysdate from dual
> > > >
> > > > Test Case 1:
> > > > no. of threads: 10
> > > > no. of connetcions: 1
> > > >
> > > > Avg Sample Time is 5 ms
> > > >
> > > > Now i increase no. of connections to 2, thinking that it would
> > decrease
> > > > sample times. But now avg. sample time moves to 200 ms. I have noticed
> > that
> > > > increasing no. of connections while keeping no. of threads constant
> > > > increases sample times. Please can someone explain this phenomenon?
> > > >
> > > > Thanks
> > > >
> > > > Regards,
> > > > Jehanzeb Qayyum
> > > >
> > > >
> > >
> >
>
> > ---------------------------------------------------------------------
> > 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
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
The target application is irrelevant.
What is important is what use-case you are trying to simulate.
If you are trying to emulate multiple independent users connecting to
your application, you should not be using connection pooling in
JMeter.
On 30/06/2010, jz <je...@gmail.com> wrote:
> Connections are pooled between threads. I am talking about a j2ee
> application.
>
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 2:27 PM, sebb <se...@gmail.com> wrote:
>
> > On 30/06/2010, jz <je...@gmail.com> wrote:
> > > Thanks
> > >
> > > Yes i am also thinking on same lines. It must be connection opening
> > > overhead. e.g. if i do this
> > >
> > > no. of threads: 10
> > > no. of connections: 10
> >
> > You should use "Max Number of Connections" = 0 otherwise connections
> > are pooled between threads, which would not happen with independent
> > users in real life.
> >
> > > ramp-up: 0 sec
> > >
> > > So these threads will open all connections. Now when i re-run the above
> > > test, will the physical connections be opened again or taken from pool
> > of
> > > previous run?
> >
> > Connections are not kept between runs.
> >
> > > I will also share, results of your idea.
> > >
> > > Regards,
> > > Jehanzeb Qayyum
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Jun 30, 2010 at 10:52 AM, Sudip Kumar Bhattacharya <
> > > skb.subscriptions@gmail.com> wrote:
> > >
> > > > Can it be related to the overhead of creating the extra connection
> > objects
> > > > and getting the connection to the db?
> > > > You can take the connection creation overhead by running your query in
> > a
> > > > loop of say hundred iteration.
> > > > Then if you average out by taking total time /total iterations, you
> > may get
> > > > the expected output.
> > > > Sent on my BlackBerry® from Vodafone
> > > >
> > > > -----Original Message-----
> > > > From: jz <je...@gmail.com>
> > > > Date: Wed, 30 Jun 2010 10:42:03
> > > > To: <jm...@jakarta.apache.org>
> > > > Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
> > > > Subject: JMetere JDBC Test Confusing Result
> > > >
> > > > Hi,
> > > >
> > > > I am running JMeter JDBC test. I am getting confusing results which
> > vary
> > > > with no. of threads and no. of connection in pool
> > > >
> > > > Query: select sysdate from dual
> > > >
> > > > Test Case 1:
> > > > no. of threads: 10
> > > > no. of connetcions: 1
> > > >
> > > > Avg Sample Time is 5 ms
> > > >
> > > > Now i increase no. of connections to 2, thinking that it would
> > decrease
> > > > sample times. But now avg. sample time moves to 200 ms. I have noticed
> > that
> > > > increasing no. of connections while keeping no. of threads constant
> > > > increases sample times. Please can someone explain this phenomenon?
> > > >
> > > > Thanks
> > > >
> > > > Regards,
> > > > Jehanzeb Qayyum
> > > >
> > > >
> > >
> >
>
> > ---------------------------------------------------------------------
> > 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
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
Connections are pooled between threads. I am talking about a j2ee
application.
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 2:27 PM, sebb <se...@gmail.com> wrote:
> On 30/06/2010, jz <je...@gmail.com> wrote:
> > Thanks
> >
> > Yes i am also thinking on same lines. It must be connection opening
> > overhead. e.g. if i do this
> >
> > no. of threads: 10
> > no. of connections: 10
>
> You should use "Max Number of Connections" = 0 otherwise connections
> are pooled between threads, which would not happen with independent
> users in real life.
>
> > ramp-up: 0 sec
> >
> > So these threads will open all connections. Now when i re-run the above
> > test, will the physical connections be opened again or taken from pool
> of
> > previous run?
>
> Connections are not kept between runs.
>
> > I will also share, results of your idea.
> >
> > Regards,
> > Jehanzeb Qayyum
> >
> >
> >
> >
> >
> > On Wed, Jun 30, 2010 at 10:52 AM, Sudip Kumar Bhattacharya <
> > skb.subscriptions@gmail.com> wrote:
> >
> > > Can it be related to the overhead of creating the extra connection
> objects
> > > and getting the connection to the db?
> > > You can take the connection creation overhead by running your query in
> a
> > > loop of say hundred iteration.
> > > Then if you average out by taking total time /total iterations, you
> may get
> > > the expected output.
> > > Sent on my BlackBerry® from Vodafone
> > >
> > > -----Original Message-----
> > > From: jz <je...@gmail.com>
> > > Date: Wed, 30 Jun 2010 10:42:03
> > > To: <jm...@jakarta.apache.org>
> > > Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
> > > Subject: JMetere JDBC Test Confusing Result
> > >
> > > Hi,
> > >
> > > I am running JMeter JDBC test. I am getting confusing results which
> vary
> > > with no. of threads and no. of connection in pool
> > >
> > > Query: select sysdate from dual
> > >
> > > Test Case 1:
> > > no. of threads: 10
> > > no. of connetcions: 1
> > >
> > > Avg Sample Time is 5 ms
> > >
> > > Now i increase no. of connections to 2, thinking that it would
> decrease
> > > sample times. But now avg. sample time moves to 200 ms. I have noticed
> that
> > > increasing no. of connections while keeping no. of threads constant
> > > increases sample times. Please can someone explain this phenomenon?
> > >
> > > Thanks
> > >
> > > Regards,
> > > Jehanzeb Qayyum
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: JMetere JDBC Test Confusing Result
Posted by sebb <se...@gmail.com>.
On 30/06/2010, jz <je...@gmail.com> wrote:
> Thanks
>
> Yes i am also thinking on same lines. It must be connection opening
> overhead. e.g. if i do this
>
> no. of threads: 10
> no. of connections: 10
You should use "Max Number of Connections" = 0 otherwise connections
are pooled between threads, which would not happen with independent
users in real life.
> ramp-up: 0 sec
>
> So these threads will open all connections. Now when i re-run the above
> test, will the physical connections be opened again or taken from pool of
> previous run?
Connections are not kept between runs.
> I will also share, results of your idea.
>
> Regards,
> Jehanzeb Qayyum
>
>
>
>
>
> On Wed, Jun 30, 2010 at 10:52 AM, Sudip Kumar Bhattacharya <
> skb.subscriptions@gmail.com> wrote:
>
> > Can it be related to the overhead of creating the extra connection objects
> > and getting the connection to the db?
> > You can take the connection creation overhead by running your query in a
> > loop of say hundred iteration.
> > Then if you average out by taking total time /total iterations, you may get
> > the expected output.
> > Sent on my BlackBerry® from Vodafone
> >
> > -----Original Message-----
> > From: jz <je...@gmail.com>
> > Date: Wed, 30 Jun 2010 10:42:03
> > To: <jm...@jakarta.apache.org>
> > Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
> > Subject: JMetere JDBC Test Confusing Result
> >
> > Hi,
> >
> > I am running JMeter JDBC test. I am getting confusing results which vary
> > with no. of threads and no. of connection in pool
> >
> > Query: select sysdate from dual
> >
> > Test Case 1:
> > no. of threads: 10
> > no. of connetcions: 1
> >
> > Avg Sample Time is 5 ms
> >
> > Now i increase no. of connections to 2, thinking that it would decrease
> > sample times. But now avg. sample time moves to 200 ms. I have noticed that
> > increasing no. of connections while keeping no. of threads constant
> > increases sample times. Please can someone explain this phenomenon?
> >
> > Thanks
> >
> > Regards,
> > Jehanzeb Qayyum
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JMetere JDBC Test Confusing Result
Posted by jz <je...@gmail.com>.
Thanks
Yes i am also thinking on same lines. It must be connection opening
overhead. e.g. if i do this
no. of threads: 10
no. of connections: 10
ramp-up: 0 sec
So these threads will open all connections. Now when i re-run the above
test, will the physical connections be opened again or taken from pool of
previous run?
I will also share, results of your idea.
Regards,
Jehanzeb Qayyum
On Wed, Jun 30, 2010 at 10:52 AM, Sudip Kumar Bhattacharya <
skb.subscriptions@gmail.com> wrote:
> Can it be related to the overhead of creating the extra connection objects
> and getting the connection to the db?
> You can take the connection creation overhead by running your query in a
> loop of say hundred iteration.
> Then if you average out by taking total time /total iterations, you may get
> the expected output.
> Sent on my BlackBerry® from Vodafone
>
> -----Original Message-----
> From: jz <je...@gmail.com>
> Date: Wed, 30 Jun 2010 10:42:03
> To: <jm...@jakarta.apache.org>
> Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
> Subject: JMetere JDBC Test Confusing Result
>
> Hi,
>
> I am running JMeter JDBC test. I am getting confusing results which vary
> with no. of threads and no. of connection in pool
>
> Query: select sysdate from dual
>
> Test Case 1:
> no. of threads: 10
> no. of connetcions: 1
>
> Avg Sample Time is 5 ms
>
> Now i increase no. of connections to 2, thinking that it would decrease
> sample times. But now avg. sample time moves to 200 ms. I have noticed that
> increasing no. of connections while keeping no. of threads constant
> increases sample times. Please can someone explain this phenomenon?
>
> Thanks
>
> Regards,
> Jehanzeb Qayyum
>
>
Re: JMetere JDBC Test Confusing Result
Posted by Sudip Kumar Bhattacharya <sk...@gmail.com>.
Can it be related to the overhead of creating the extra connection objects and getting the connection to the db?
You can take the connection creation overhead by running your query in a loop of say hundred iteration.
Then if you average out by taking total time /total iterations, you may get the expected output.
Sent on my BlackBerry® from Vodafone
-----Original Message-----
From: jz <je...@gmail.com>
Date: Wed, 30 Jun 2010 10:42:03
To: <jm...@jakarta.apache.org>
Reply-To: "JMeter Users List" <jm...@jakarta.apache.org>
Subject: JMetere JDBC Test Confusing Result
Hi,
I am running JMeter JDBC test. I am getting confusing results which vary
with no. of threads and no. of connection in pool
Query: select sysdate from dual
Test Case 1:
no. of threads: 10
no. of connetcions: 1
Avg Sample Time is 5 ms
Now i increase no. of connections to 2, thinking that it would decrease
sample times. But now avg. sample time moves to 200 ms. I have noticed that
increasing no. of connections while keeping no. of threads constant
increases sample times. Please can someone explain this phenomenon?
Thanks
Regards,
Jehanzeb Qayyum