jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: JDBC PreparedStatement Cache
Date Wed, 07 Sep 2016 20:00:41 GMT
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