[
https://issues.apache.org/jira/browse/ARTEMIS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro updated ARTEMIS-2955:
-------------------------------------
Description:
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.
Just for reference, in violet, that's the amount of "heavy" work performed by
EmbeddedDataSource if we use commons-dbcp2:
!screenshot-1.png!
It 's clear that the update row is performing a huge additional amount of
work...
I suggest to disable commons-dbcp2 for Derby and investigate if it could happen
in a real broker too.
was:
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.
I suggest to disable commons-dbcp2 for Derby and investigate if it could happen
in a real broker too.
> 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
>
>
> 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.
> Just for reference, in violet, that's the amount of "heavy" work performed by
> EmbeddedDataSource if we use commons-dbcp2:
> !screenshot-1.png!
> It 's clear that the update row is performing a huge additional amount of
> work...
> 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)
