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 Thu, 08 Sep 2016 05:38:10 GMT


Am 8. September 2016 01:17:52 MESZ, schrieb sebb <sebbaz@gmail.com>:
>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.

I am not sure I can follow you. I read it as: first, you are in favour to remove or cache
as it made connections between the threads. Second, you want a new way to keep a connection
(and prepared statements) for the whole test run for each thread. 

Right? 

My concern was about the statements that are not reachable by the client and are not closed,
which again will lead to a memory leak. So I think we should close the statements in the current
implementation. 

Regards, 
Felix 

>
>
>On 7 September 2016 at 21:00, Felix Schumacher
><felix.schumacher@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
>>>
>>


Mime
View raw message