Generally, when I'm analyzing MySQL Performance on Linux with "localhost" test workloads, I'm configuring client connections to use IP port (loopback) to connect to MySQL Server (and not UNIX socket) -- this is still at least involving IP stack in the game, and if something is going odd on IP, we can be aware ahead about. And indeed, it already helped several times to discover such kind of problems even without network links between client/server (like this one, etc.). However, in the past we also observed a pretty significant difference in QPS results when IP port was used comparing to UNIX socket (communications via UNIX socket were going near 15% faster).. Over a time with newer OL kernel releases this gap became smaller and smaller. But in all such cases it's always hard to say if the gap was reduced due OS kernel / IP stack improvements, or it's just because MySQL Server is hitting new scalability bottlenecks ;-))

Anyway, I've still continued to use IP port in all my tests until now. But recently the same discussion about IP port impact -vs- UNIX socket came up again in other investigations, and I'd like to share the results I've obtained on different HW servers with MySQL 8.0 GA release.

The test workload is the most "aggressive" for client/server ping-pong exchange -- Sysbench point-selects (the same test scenario which initially already reported 2.1M QPS on MySQL 8.0) -- but this time on 3 different servers :

and see how different the results will be when exactly the same test is running via IP port / or UNIX socket.

- IP port :

- UNIX socket :

Comments :

- IP port :

- UNIX socket :

Comments :

- IP port :

- UNIX socket :

Comments :

But why on high load we're not seeing such a big difference ?.. -- one of the explanation is a higher overhead we have now at least from open_table() code which is involved on every query, and on 2M QPS rate it becomes pretty visible.

The following graph is representing Sysbench point-select workload in time line -- the load is starting with 1 user, then 2 users, 4, .. and 1024 :

and the next graph is tracing the most hot functions reported by "perf" profiler since the load level becomes high enough (4 - 1024 users) :

as you can see, open_table() is going up with a growing load, and growing pthread_mutex_lock() times (involved from open_table()) are pointing on a real bottleneck here..

While it's clear as well that some other part of code are also willing more love.. -- if we only could have all the time we need to fix all we want ;-))

Thank you for using MySQL ! -- stay tuned ;-))

Rgds,

-Dimitri