Last Friday I published results of DBT2 performance while varying the number of idle connections here, but I had compiled MySQL with the debugging code enabled. That completely screw up my results, be aware… debug options have a huge performance impact. So, I recompiled Percona-Server 11.2 without the debug options and did another benchmark run. The result is shown below:
As you can see, the impact is more moderate and far less shocking. The performance loss is approximately of 1% per 1000 of idle connections. Although it is something to keep in mind, there is no big stress with these idle connections.
Yves,
Thanks for update. Note the cost of connection handling you imply here should be constant per query… meaning the overhead could be higher with very fast connections. The NoTPM number you showed here is rather low which means number of queries was low for some reason (data size, cost of commit, I do not know) It would be really interesting to see the same graph for sysbench PK reads, which is basically as fast as it gets… the overhead could be larger
Not as shocking indeed, but still considerable. Thanks for testing this and publishing your results!
Cheers,
Tim Vaillancourt
I think scaling the y axis on the graph from 0 .. 6000 as opposed to 5600 … 6000 would give a better visual indication that this is a very minor decline.
Just glancing at the graph (as I did this morning) made me do a double take.
I agree with Patrick. Edward Tufte would beat you with a whip 🙂
Just so everyone is on the same page (got people asking me):
NOTPM, New Order Transactions per Minute
Why the correlation between No.of idle connect and performance is negative?
Is it because MySQL implements the multiple port request by ‘select method’?