You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Francesco Nigro (Jira)" <ji...@apache.org> on 2020/10/20 07:18:00 UTC
[jira] [Updated] (ARTEMIS-2955) commons-dbcp2 performance issue
with Derby Embedded DBMS
[ 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
Improve JDBC connection management|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.
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
Improve JDBC connection management|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 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
>
>
> 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
> Improve JDBC connection management|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.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)