Weird issue. I'm trying to figure out how the connection pool can add an overhead to a single query. The only case I can think is if you use a network storage engine (Federated, Connect, Spider) pointing to tables on localhost. Is this the case?
More likely... are you sure this problem is caused by the connection pool?
* After the first execution, do a SHOW STATUS. Then FLUSH STATUS. Then execute again and, if it takes long time, do another SHOW STATUS. Post your results here, so we can see what happened.
* While the query takes a long time, try a SHOW PROCESSLIST from another client. See if the connection is waiting for a lock.
Regards
Federico
--------------------------------------------
Mar 14/6/16, Stu Smith ha scritto:
Oggetto: [Maria-discuss] Odd behavior with query and connection pool
A: maria-discuss@lists.launchpad.net
Data: Martedì 14 giugno 2016, 03:36
Hello,
Forgive me for reporting this on the behalf of some
other developers, I will gather more details as needed.
But the basic problem we're having is with a query
that:
- is always fast the first time ( < 3 seconds
)
- is very slow the following time, when using a
connection pool (~ 30 seconds)
- is pretty fast the following time, when not
using a connection pool (5 or 6 seconds)
This is even on a single DB with no other load.
It's a fairly complicated query with sub queries,
grouping, and such.
I've been told it creates two temp tables.
I know this is not a whole lot to go one - but
are there any pointer for connection pool vs no connection
pool on a lightly loaded DB?
This was actually tried and reproduced with
multiple connection pools - hikari-db, c3p0, and apache
connection pool.
Take care,
-stu
-----Segue allegato-----
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
