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
