maria-discuss team mailing list archive
Mailing list archive
R: Odd behavior with query and connection pool
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.
Mar 14/6/16, Stu Smith <stu26code@xxxxxxxxx> ha scritto:
Oggetto: [Maria-discuss] Odd behavior with query and connection pool
Data: Martedì 14 giugno 2016, 03:36
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
- 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
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp