On 14 March 2012 13:03, Shmuel Krakower <[email protected]> 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 <[email protected]> wrote: > >> On 14 March 2012 12:36, Shmuel Krakower <[email protected]> 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" <[email protected]>: >> > >> >> On 14 March 2012 09:24, Shmuel Krakower <[email protected]> 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
