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.schumac...@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 >> >
