On 15 March 2012 16:36, Shmuel Krakower <[email protected]> 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 <[email protected]> wrote: > >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
