[CONJ-509] Query performance issue when using mariadb driver instead of mysql driver when connecting to aws aurara db Created: 2017-07-26  Updated: 2017-09-20  Resolved: 2017-09-20

Status: Closed
Project: MariaDB Connector/J
Component/s: aurora
Affects Version/s: 1.4.6
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Pankaj Assignee: Diego Dupin
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

AWS Aurara db



 Description   

When a query is executed on database using workbench (sql client) directly, it returns in around 500 ms.
But when its executed from java layer (either through mybatis or spring named template) using mariadb driver, query behaves differently.
First execution takes around 1 second but subsequent execution takes around 45-50 seconds. This is consistently reproducible.
It is observed that when query is waiting for response from jdbc layer, tables involved in query are locked.
When we change jdbc driver from mariadb to mysql driver, then query performance responds consistently in 1-2 seconds for all execution.

For now, we have switched to mysql driver for connecting to AWS Aurara db. AWS recommends to use mariadb driver but we are planning to revert to mysql driver for now to tackle this issue.

Query:
SELECT SQL_CALC_FOUND_ROWS group_key, max(tasks.create_time_) max_create_date, count(tasks.id_) tasks_count from ( select distinct task.* from ACT_RU_TASK task left outer join ACT_RU_IDENTITYLINK idlink on task.id_ = idlink.task_id_ and idlink.type_ = 'candidate' where (lower(task.assignee_) = 'user1' or lower(idlink.user_id_) = 'user1') and (task.FOLLOW_UP_DATE_ is null or task.FOLLOW_UP_DATE_ <= '2017-07-25 00:26:02')) tasks, (select PROC_INST_ID_, text_ group_key from ACT_RU_VARIABLE where name_ = 'var1' ) taskVars where tasks.proc_inst_id_ = taskVars.proc_inst_id_ group by group_key order by max(tasks.create_time_) desc limit 0, 0;

Thanks.



 Comments   
Comment by Diego Dupin [ 2017-07-27 ]

This seems to be a "second execution" issue from aurora.
There was this kind of issue with MariaDB server, but that has been corrected since.

You could use set the option "useServerPrepStmts" to false. (This is now the default value since 1.6.x). This will correct this problem - MySQL driver use that option by default.
when useServerPrepStmts is set, driver use binary protocol, meaning executing a PREPARE command, then EXECUTE many times with different parameters. At some point, Aurora must lost some information and make a full table scan.

Could you try this and confirm the issue (and then report that to Amazon)

Comment by Diego Dupin [ 2017-08-23 ]

Mandaliya, did you read previous comment, and set option "useServerPrepStmts" to false / use last driver version ?

Comment by Diego Dupin [ 2017-09-20 ]

closing since no response from creation since more than a month.

Generated at Thu Feb 08 03:16:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.