jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: JDBC PreparedStatement Cache
Date Tue, 06 Sep 2016 19:24:35 GMT
TL;DR: +1 for removing caching at JMeter side.

I believe most applications never reuse prepared statements (I mean they
never reuse PreparedStatement java objects).
They just follow ps=con.prepareStatement(..);; 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( 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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message