[
https://issues.apache.org/jira/browse/ARTEMIS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217432#comment-17217432
]
Francesco Nigro edited comment on ARTEMIS-2955 at 10/20/20, 8:35 AM:
---------------------------------------------------------------------
Thanks to the great suggestion of [~gtully], this is going to fix a "likely"
performance issue on the broker, not just on the test: going to update the JIRA.
See the resulting flamegraph
!screenshot-2.png!
There is no more traces of reflective access nor creation of prepared
statements and perfs are even better then using EmbeddedDataSource given that
we don't allocate anymore a new connection each time.
Please [~mikkommku] take a look to my PR (will send it soon) so I know I'm not
impacting anything for you as well: it's very likely I'm going to turn on
poolPreparedStatements by default and users can choose if they prefer to change
it to false by manually setting it, in case.
one question about
{quote}The reason I did not enable it on my pull request was that it's not
something universal that's available on alternative datasources, and couldn't
quite figure out whether implementation changes were needed to prepare for use
of other datasources.{quote}
I'm just using
{code:java}
addDataSourceProperty("poolPreparedStatements", "true");
{code}
if dataSourceProperties.isEmpty() but I see a
{code:java}
addDataSourceProperty("maxTotal", "-1");
{code}
Probably we should check if the data source class used is the default one
before setting both these default, I don't think "maxTotal" is available to
other data source solutions as well.
was (Author: nigrofranz):
Thanks to the great suggestion of [~gtully], this is going to fix a "likely"
performance issue on the broker, not just on the test: going to update the JIRA.
See the resulting flamegraph
!screenshot-2.png!
There is no more traces of reflective access nor creation of prepared
statements and perfs are even better then using EmbeddedDataSource given that
we don't allocate anymore a new connection each time.
Please [~mikkommku] take a look to my PR (will send it soon) so I know I'm not
impacting anything for you as well: it's very likely I'm going to turn on
poolPreparedStatements by default and users can choose if they prefer to change
it to false by manually setting it, in case.
> commons-dbcp2 performance issue with Derby Embedded DBMS
> --------------------------------------------------------
>
> Key: ARTEMIS-2955
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2955
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Tests
> Affects Versions: 2.16.0
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Attachments: image-2020-10-20-09-08-45-390.png,
> image-2020-10-20-09-10-10-644.png, pooling_off.svg, pooling_on.svg,
> screenshot-1.png, screenshot-2.png
>
>
> The test suite has shown an increase in duration of 30 minutes going from to
> 2:30 to 3 hours: it seems related to integration paging tests running on
> Embedded Derby with the changes of
> [ARTEMIS-2823|https://issues.apache.org/jira/browse/ARTEMIS-2823].
> After some profiling sessions on
> org/apache/activemq/artemis/tests/integration/paging/PagingTest.testQueueRemoveAll
> it seems that using commons-dbcp2 with Embedded Derby isn't working as
> expected:
> !image-2020-10-20-09-08-45-390.png!
> while, if we switch to
> [EmbeddedDataSource|https://db.apache.org/derby/docs/10.13/publishedapi/org/apache/derby/jdbc/EmbeddedDataSource.html]
> we have
> !image-2020-10-20-09-10-10-644.png!
> By not using commons-dbcp2 we get roughtly a ~10X improvement in performance:
> it seems that commons-dbcp2 is forcing to setup from the ground the prepared
> statement each time, while EmbeddedDataSource nope. Specifically it seems
> related to Derby GenericActivationHolder.
> I suggest to disable commons-dbcp2 for Derby and investigate if it could
> happen in a real broker too.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
