jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JDBC PreparedStatement Cache
Date Wed, 07 Sep 2016 23:17:52 GMT
It seems to me that it ought to be possible to re-use a
PreparedStatement somehow in JMeter.
Surely re-use is one of the functions of a PreparedStatement?

However I've always thought that pooling across threads (or indeed
caching across threads) does not make sense given that threads are
supposed to represent independent users.
That sort of re-use just reduces the load on the database server, when
the main point is surely to test the server.


On 7 September 2016 at 21:00, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
> Am 06.09.2016 um 21:24 schrieb Vladimir Sitnikov:
>>
>> TL;DR: +1 for removing caching at JMeter side.
>
> Thanks for the detailed test. I believe we are missing the close statements
> for the prepared statements. Will have a look at that tomorrow.
>
> Regards,
>  Felix
>
>>
>> I believe most applications never reuse prepared statements (I mean they
>> never reuse PreparedStatement java objects).
>> They just follow ps=con.prepareStatement(..);...ps.close(); pattern.
>>
>> So, if JMeter used "always go through con.prepareStatement" mode, then it
>> would accurately model the performance for those applications.
>>
>>
>> Just in case, I've did a single-threaded JMH benchmark (see [1]) against
>> localhost on OSX 10.11 for PostgreSQL jdbc driver (pgjdbc) to check what
>> is
>> the impact for "reused vs non-reused" statement execution.
>> The statement is "select 1" that produces 1 row and 1 column. Resultset is
>> processed as "while(re.next()) rs.getInt(1)".
>>
>> Here are the results:
>> Benchmark                                             (reuseStatement)
>>   Mode  Cnt    Score      Error   Units
>> ProcessResultSet.bindExecuteFetch                                 true
>>   avgt   10   38,899 ±    0,508   us/op
>> ProcessResultSet.bindExecuteFetch:·gc.alloc.rate.norm             true
>>   avgt   10  464,069 ±    0,228    B/op
>> ProcessResultSet.bindExecuteFetch                                false
>>   avgt   10   39,724 ±    0,454   us/op
>> ProcessResultSet.bindExecuteFetch:·gc.alloc.rate.norm            false
>>   avgt   10  752,070 ±    0,232    B/op
>>
>> The response time difference is 38.9us vs 39.7us, and the number of
>> allocated bytes is 464 vs 752. Well, I think JMeter is not supposed to
>> measure that level of details, so it is perfectly fine to ignore that at
>> JMeter side.
>>
>> PS. If you think 464 vs 752 is significant, then remember that the case is
>> sending just 4 bytes (1 int). For bigger queries the resultset size would
>> greatly exceed that (752-464) difference.
>>
>> PPS. Bonus point for those who read this: I wonder what do you thing of
>> adding "number of bytes allocated" as one more measurement done by JMeter
>> (in addition to "response time")?
>> It would make great sense, especially for Java samplers. OpenJDK 1.6u26+
>> allows easy way to capture "number of bytes allocated" from a
>> ThreadMXBean.
>>
>> [1]:
>>
>> https://github.com/pgjdbc/pgjdbc/blob/master/ubenchmark/src/main/java/org/postgresql/benchmark/statement/ProcessResultSet.java
>>
>>
>> Vladimir
>>
>

Mime
View raw message