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(..);...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
