[ 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. 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 > > > 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. > -- This message was sent by Atlassian Jira (v8.3.4#803005)