You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Shmuel Krakower <sh...@gmail.com> on 2012/03/14 10:24:52 UTC
JDBC Sampler Load Time Vs. Latency
Hi,
I am load testing a DB with JDBC sampler and noticed that the load time of
each sample is much higher than the actual time it took the DB to respond.
It seems like the time to render the results by JMeter is getting into the
Load Time while what's really important is just the Latency.
That makes it impossible to work with any listener to understand what are
the actual response times of each SQL.
Is that a known problem, or I just miss something?
Regards,
Shmuel Krakower.
Re: JDBC Sampler Load Time Vs. Latency
Posted by sebb <se...@gmail.com>.
On 15 March 2012 16:36, Shmuel Krakower <sh...@gmail.com> wrote:
> Thanks for staying with me.
> OK I missunderstood that latency is only the CONNECTION time.
>
> So in that case let me clarify better.
> My problem is that I need to load test a DB while some of the SQLs I need
> to run returns huge datasets.
> The problem with that is that JMeter is parsing the result and loading it
> into dataset object.
> Now I get the feeling that this parsing time is also included in the Load
> Time, thus making it impossible to tell if most of the time was spent in
> JMeter or on DB.
>
> I didn't want to guess so I just checked the code of JDBCSampler and it
> really is a problem.
> Wouldn't it make sense to move the "res.sampleEnd()" to right after
> each executeQuery/Command()
> and before res.setResponseData()?
That won't show the time spent retrieving the data.
If multiple rows are returned, JMeter has to call ResultSet#getNext()
which may involve fetching more data from the server.
> Regards,
>
> Shmuel.
>
> On Wed, Mar 14, 2012 at 3:25 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 March 2012 13:03, Shmuel Krakower <sh...@gmail.com> wrote:
>> > Thanks for the answers.
>> >
>> > If I understand you correctly, for the JDBC Sampler:
>> > 1. Latency = time from SQL sent until the response arrived completely.
>>
>> No, as I just wrote:
>>
>> "For the JDBC Sampler, latency is the connection time."
>>
>> i.e. the time to get the connection
>>
>> > 2. Load Time = response time / latency + some initial process of the
>> > result (in JDBC case - loading the response into a dataset).
>>
>> Yes, as would be the case for any JDBC client.
>>
>> If you want to see how long it takes for a single row to be returned,
>> then request a single row.
>>
>> > If that's true - it means that any listener like Aggregate Report or
>> other
>> > JMeterPlugins visualizers will show the response time based on load time.
>>
>> Yes, that's how JMeter works.
>>
>> > This is not good in case I get a huge dataset back from the DB server, as
>> > it seems like I have queries which takes less than 10 ms to complete
>> > (latency=10) but response time shown on these listeners is very high,
>> like
>> > 10-30 seconds because of the fact the this JDBC sampler is trying to load
>> > the resulting rows.
>>
>> If the sample requests lots of rows, then it is going to take longer to
>> process.
>>
>> > So that's why I trick the jtl file and then load it into the listeners to
>> > visualize me with the latency and not load time.
>> >
>> > Does it make any sense?
>>
>> No, because latency is the connection time for the JDBC sampler.
>>
>> >
>> > Shmuel.
>> > On Wed, Mar 14, 2012 at 2:48 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 14 March 2012 12:36, Shmuel Krakower <sh...@gmail.com> wrote:
>> >> > Hi,
>> >> > Basically it prevents me from using any response time value detailed
>> in
>> >> > aggregate or summary reports as I only care for the response times.
>> >>
>> >> So just ignore the latency?
>> >>
>> >> > Now I know that using latency instead of load time on these reports is
>> >> not
>> >> > something we can do (as people will need to be aware of such a
>> dramatic
>> >> > change).
>> >> > But when thinking of it, why are all reports using the load time value
>> >> and
>> >> > not latency? Wouldn't it be more accurate (show only latency and not
>> >> JMeter
>> >> > affects)?
>> >>
>> >> No.
>> >>
>> >> Latency was not always present, and is not yet available for all
>> samplers.
>> >> For some it may not make sense.
>> >>
>> >> Elapsed time does not include any JMeter processing, apart from that
>> >> which is necessary to finish receiving all the data.
>> >>
>> >> > Currently I am working around this by editing the jtl file and change
>> the
>> >> > field name, to trick the summary reports.
>> >>
>> >> Why?
>> >>
>> >> I think you may be misunderstanding how JMeter works.
>> >>
>> >>
>> >> > Regards,
>> >> > Shmuel.
>> >> > בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
>> >> >
>> >> >> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
>> >> >> > Hi,
>> >> >> > I am load testing a DB with JDBC sampler and noticed that the load
>> >> time
>> >> >> of
>> >> >> > each sample is much higher than the actual time it took the DB to
>> >> >> respond.
>> >> >> > It seems like the time to render the results by JMeter is getting
>> into
>> >> >> the
>> >> >> > Load Time while what's really important is just the Latency.
>> >> >> >
>> >> >> > That makes it impossible to work with any listener to understand
>> what
>> >> are
>> >> >> > the actual response times of each SQL.
>> >> >> >
>> >> >> > Is that a known problem, or I just miss something?
>> >> >>
>> >> >> For the JDBC Sampler, latency is the connection time.
>> >> >> This ought to be documented, but does not seem to be.
>> >> >>
>> >> >> > Regards,
>> >> >> > Shmuel Krakower.
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JDBC Sampler Load Time Vs. Latency
Posted by Shmuel Krakower <sh...@gmail.com>.
Thanks for staying with me.
OK I missunderstood that latency is only the CONNECTION time.
So in that case let me clarify better.
My problem is that I need to load test a DB while some of the SQLs I need
to run returns huge datasets.
The problem with that is that JMeter is parsing the result and loading it
into dataset object.
Now I get the feeling that this parsing time is also included in the Load
Time, thus making it impossible to tell if most of the time was spent in
JMeter or on DB.
I didn't want to guess so I just checked the code of JDBCSampler and it
really is a problem.
Wouldn't it make sense to move the "res.sampleEnd()" to right after
each executeQuery/Command()
and before res.setResponseData()?
Regards,
Shmuel.
On Wed, Mar 14, 2012 at 3:25 PM, sebb <se...@gmail.com> wrote:
> On 14 March 2012 13:03, Shmuel Krakower <sh...@gmail.com> wrote:
> > Thanks for the answers.
> >
> > If I understand you correctly, for the JDBC Sampler:
> > 1. Latency = time from SQL sent until the response arrived completely.
>
> No, as I just wrote:
>
> "For the JDBC Sampler, latency is the connection time."
>
> i.e. the time to get the connection
>
> > 2. Load Time = response time / latency + some initial process of the
> > result (in JDBC case - loading the response into a dataset).
>
> Yes, as would be the case for any JDBC client.
>
> If you want to see how long it takes for a single row to be returned,
> then request a single row.
>
> > If that's true - it means that any listener like Aggregate Report or
> other
> > JMeterPlugins visualizers will show the response time based on load time.
>
> Yes, that's how JMeter works.
>
> > This is not good in case I get a huge dataset back from the DB server, as
> > it seems like I have queries which takes less than 10 ms to complete
> > (latency=10) but response time shown on these listeners is very high,
> like
> > 10-30 seconds because of the fact the this JDBC sampler is trying to load
> > the resulting rows.
>
> If the sample requests lots of rows, then it is going to take longer to
> process.
>
> > So that's why I trick the jtl file and then load it into the listeners to
> > visualize me with the latency and not load time.
> >
> > Does it make any sense?
>
> No, because latency is the connection time for the JDBC sampler.
>
> >
> > Shmuel.
> > On Wed, Mar 14, 2012 at 2:48 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 14 March 2012 12:36, Shmuel Krakower <sh...@gmail.com> wrote:
> >> > Hi,
> >> > Basically it prevents me from using any response time value detailed
> in
> >> > aggregate or summary reports as I only care for the response times.
> >>
> >> So just ignore the latency?
> >>
> >> > Now I know that using latency instead of load time on these reports is
> >> not
> >> > something we can do (as people will need to be aware of such a
> dramatic
> >> > change).
> >> > But when thinking of it, why are all reports using the load time value
> >> and
> >> > not latency? Wouldn't it be more accurate (show only latency and not
> >> JMeter
> >> > affects)?
> >>
> >> No.
> >>
> >> Latency was not always present, and is not yet available for all
> samplers.
> >> For some it may not make sense.
> >>
> >> Elapsed time does not include any JMeter processing, apart from that
> >> which is necessary to finish receiving all the data.
> >>
> >> > Currently I am working around this by editing the jtl file and change
> the
> >> > field name, to trick the summary reports.
> >>
> >> Why?
> >>
> >> I think you may be misunderstanding how JMeter works.
> >>
> >>
> >> > Regards,
> >> > Shmuel.
> >> > בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
> >> >
> >> >> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
> >> >> > Hi,
> >> >> > I am load testing a DB with JDBC sampler and noticed that the load
> >> time
> >> >> of
> >> >> > each sample is much higher than the actual time it took the DB to
> >> >> respond.
> >> >> > It seems like the time to render the results by JMeter is getting
> into
> >> >> the
> >> >> > Load Time while what's really important is just the Latency.
> >> >> >
> >> >> > That makes it impossible to work with any listener to understand
> what
> >> are
> >> >> > the actual response times of each SQL.
> >> >> >
> >> >> > Is that a known problem, or I just miss something?
> >> >>
> >> >> For the JDBC Sampler, latency is the connection time.
> >> >> This ought to be documented, but does not seem to be.
> >> >>
> >> >> > Regards,
> >> >> > Shmuel Krakower.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: JDBC Sampler Load Time Vs. Latency
Posted by sebb <se...@gmail.com>.
On 14 March 2012 13:03, Shmuel Krakower <sh...@gmail.com> wrote:
> Thanks for the answers.
>
> If I understand you correctly, for the JDBC Sampler:
> 1. Latency = time from SQL sent until the response arrived completely.
No, as I just wrote:
"For the JDBC Sampler, latency is the connection time."
i.e. the time to get the connection
> 2. Load Time = response time / latency + some initial process of the
> result (in JDBC case - loading the response into a dataset).
Yes, as would be the case for any JDBC client.
If you want to see how long it takes for a single row to be returned,
then request a single row.
> If that's true - it means that any listener like Aggregate Report or other
> JMeterPlugins visualizers will show the response time based on load time.
Yes, that's how JMeter works.
> This is not good in case I get a huge dataset back from the DB server, as
> it seems like I have queries which takes less than 10 ms to complete
> (latency=10) but response time shown on these listeners is very high, like
> 10-30 seconds because of the fact the this JDBC sampler is trying to load
> the resulting rows.
If the sample requests lots of rows, then it is going to take longer to process.
> So that's why I trick the jtl file and then load it into the listeners to
> visualize me with the latency and not load time.
>
> Does it make any sense?
No, because latency is the connection time for the JDBC sampler.
>
> Shmuel.
> On Wed, Mar 14, 2012 at 2:48 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 March 2012 12:36, Shmuel Krakower <sh...@gmail.com> wrote:
>> > Hi,
>> > Basically it prevents me from using any response time value detailed in
>> > aggregate or summary reports as I only care for the response times.
>>
>> So just ignore the latency?
>>
>> > Now I know that using latency instead of load time on these reports is
>> not
>> > something we can do (as people will need to be aware of such a dramatic
>> > change).
>> > But when thinking of it, why are all reports using the load time value
>> and
>> > not latency? Wouldn't it be more accurate (show only latency and not
>> JMeter
>> > affects)?
>>
>> No.
>>
>> Latency was not always present, and is not yet available for all samplers.
>> For some it may not make sense.
>>
>> Elapsed time does not include any JMeter processing, apart from that
>> which is necessary to finish receiving all the data.
>>
>> > Currently I am working around this by editing the jtl file and change the
>> > field name, to trick the summary reports.
>>
>> Why?
>>
>> I think you may be misunderstanding how JMeter works.
>>
>>
>> > Regards,
>> > Shmuel.
>> > בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
>> >
>> >> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
>> >> > Hi,
>> >> > I am load testing a DB with JDBC sampler and noticed that the load
>> time
>> >> of
>> >> > each sample is much higher than the actual time it took the DB to
>> >> respond.
>> >> > It seems like the time to render the results by JMeter is getting into
>> >> the
>> >> > Load Time while what's really important is just the Latency.
>> >> >
>> >> > That makes it impossible to work with any listener to understand what
>> are
>> >> > the actual response times of each SQL.
>> >> >
>> >> > Is that a known problem, or I just miss something?
>> >>
>> >> For the JDBC Sampler, latency is the connection time.
>> >> This ought to be documented, but does not seem to be.
>> >>
>> >> > Regards,
>> >> > Shmuel Krakower.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JDBC Sampler Load Time Vs. Latency
Posted by Shmuel Krakower <sh...@gmail.com>.
Thanks for the answers.
If I understand you correctly, for the JDBC Sampler:
1. Latency = time from SQL sent until the response arrived completely.
2. Load Time = response time / latency + some initial process of the
result (in JDBC case - loading the response into a dataset).
If that's true - it means that any listener like Aggregate Report or other
JMeterPlugins visualizers will show the response time based on load time.
This is not good in case I get a huge dataset back from the DB server, as
it seems like I have queries which takes less than 10 ms to complete
(latency=10) but response time shown on these listeners is very high, like
10-30 seconds because of the fact the this JDBC sampler is trying to load
the resulting rows.
So that's why I trick the jtl file and then load it into the listeners to
visualize me with the latency and not load time.
Does it make any sense?
Shmuel.
On Wed, Mar 14, 2012 at 2:48 PM, sebb <se...@gmail.com> wrote:
> On 14 March 2012 12:36, Shmuel Krakower <sh...@gmail.com> wrote:
> > Hi,
> > Basically it prevents me from using any response time value detailed in
> > aggregate or summary reports as I only care for the response times.
>
> So just ignore the latency?
>
> > Now I know that using latency instead of load time on these reports is
> not
> > something we can do (as people will need to be aware of such a dramatic
> > change).
> > But when thinking of it, why are all reports using the load time value
> and
> > not latency? Wouldn't it be more accurate (show only latency and not
> JMeter
> > affects)?
>
> No.
>
> Latency was not always present, and is not yet available for all samplers.
> For some it may not make sense.
>
> Elapsed time does not include any JMeter processing, apart from that
> which is necessary to finish receiving all the data.
>
> > Currently I am working around this by editing the jtl file and change the
> > field name, to trick the summary reports.
>
> Why?
>
> I think you may be misunderstanding how JMeter works.
>
>
> > Regards,
> > Shmuel.
> > בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
> >
> >> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
> >> > Hi,
> >> > I am load testing a DB with JDBC sampler and noticed that the load
> time
> >> of
> >> > each sample is much higher than the actual time it took the DB to
> >> respond.
> >> > It seems like the time to render the results by JMeter is getting into
> >> the
> >> > Load Time while what's really important is just the Latency.
> >> >
> >> > That makes it impossible to work with any listener to understand what
> are
> >> > the actual response times of each SQL.
> >> >
> >> > Is that a known problem, or I just miss something?
> >>
> >> For the JDBC Sampler, latency is the connection time.
> >> This ought to be documented, but does not seem to be.
> >>
> >> > Regards,
> >> > Shmuel Krakower.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: JDBC Sampler Load Time Vs. Latency
Posted by sebb <se...@gmail.com>.
On 14 March 2012 12:36, Shmuel Krakower <sh...@gmail.com> wrote:
> Hi,
> Basically it prevents me from using any response time value detailed in
> aggregate or summary reports as I only care for the response times.
So just ignore the latency?
> Now I know that using latency instead of load time on these reports is not
> something we can do (as people will need to be aware of such a dramatic
> change).
> But when thinking of it, why are all reports using the load time value and
> not latency? Wouldn't it be more accurate (show only latency and not JMeter
> affects)?
No.
Latency was not always present, and is not yet available for all samplers.
For some it may not make sense.
Elapsed time does not include any JMeter processing, apart from that
which is necessary to finish receiving all the data.
> Currently I am working around this by editing the jtl file and change the
> field name, to trick the summary reports.
Why?
I think you may be misunderstanding how JMeter works.
> Regards,
> Shmuel.
> בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
>
>> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
>> > Hi,
>> > I am load testing a DB with JDBC sampler and noticed that the load time
>> of
>> > each sample is much higher than the actual time it took the DB to
>> respond.
>> > It seems like the time to render the results by JMeter is getting into
>> the
>> > Load Time while what's really important is just the Latency.
>> >
>> > That makes it impossible to work with any listener to understand what are
>> > the actual response times of each SQL.
>> >
>> > Is that a known problem, or I just miss something?
>>
>> For the JDBC Sampler, latency is the connection time.
>> This ought to be documented, but does not seem to be.
>>
>> > Regards,
>> > Shmuel Krakower.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JDBC Sampler Load Time Vs. Latency
Posted by Shmuel Krakower <sh...@gmail.com>.
Hi,
Basically it prevents me from using any response time value detailed in
aggregate or summary reports as I only care for the response times.
Now I know that using latency instead of load time on these reports is not
something we can do (as people will need to be aware of such a dramatic
change).
But when thinking of it, why are all reports using the load time value and
not latency? Wouldn't it be more accurate (show only latency and not JMeter
affects)?
Currently I am working around this by editing the jtl file and change the
field name, to trick the summary reports.
Regards,
Shmuel.
בתאריך 2012 3 14 14:19, מאת "sebb" <se...@gmail.com>:
> On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
> > Hi,
> > I am load testing a DB with JDBC sampler and noticed that the load time
> of
> > each sample is much higher than the actual time it took the DB to
> respond.
> > It seems like the time to render the results by JMeter is getting into
> the
> > Load Time while what's really important is just the Latency.
> >
> > That makes it impossible to work with any listener to understand what are
> > the actual response times of each SQL.
> >
> > Is that a known problem, or I just miss something?
>
> For the JDBC Sampler, latency is the connection time.
> This ought to be documented, but does not seem to be.
>
> > Regards,
> > Shmuel Krakower.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: JDBC Sampler Load Time Vs. Latency
Posted by sebb <se...@gmail.com>.
On 14 March 2012 09:24, Shmuel Krakower <sh...@gmail.com> wrote:
> Hi,
> I am load testing a DB with JDBC sampler and noticed that the load time of
> each sample is much higher than the actual time it took the DB to respond.
> It seems like the time to render the results by JMeter is getting into the
> Load Time while what's really important is just the Latency.
>
> That makes it impossible to work with any listener to understand what are
> the actual response times of each SQL.
>
> Is that a known problem, or I just miss something?
For the JDBC Sampler, latency is the connection time.
This ought to be documented, but does not seem to be.
> Regards,
> Shmuel Krakower.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org