Since MySQL's wire protocol does not support Pipeline, it is a typical short-term request/response model, which results in a lot of syscalls to kernel in tidb-server. This problem is not obvious when tidb-server calls tikv via grpc, because grpc (using http2) handle batch and pipeline well, so the effect is not obvious, but the same means may have better effect when handling mysql network requests. I think it's a worthwhile experiment, so a few things could be done.
confirm that io_uring will bring enough benefit over epoll for req/resp-like workloads
implement a high performance golang version of iouring library, subject to 1.
use 2 to replace the existing tidb-server front-end network framework
For 1, I have already started preliminary work, using iouring on a simple echo server gives roughly ~15% performance improvement (vs epoll), and this test is only on a single core cloud server, I believe it will work better on a more decent hardware, the code is available at: https:// github.com/c4pt0r/io_uring-echo-server
Kudos to @ngaut, who contributed the original idea.
Since MySQL's wire protocol does not support Pipeline, it is a typical short-term request/response model, which results in a lot of syscalls to kernel in tidb-server. This problem is not obvious when tidb-server calls tikv via grpc, because grpc (using http2) handle batch and pipeline well, so the effect is not obvious, but the same means may have better effect when handling mysql network requests. I think it's a worthwhile experiment, so a few things could be done.
For 1, I have already started preliminary work, using iouring on a simple echo server gives roughly ~15% performance improvement (vs epoll), and this test is only on a single core cloud server, I believe it will work better on a more decent hardware, the code is available at: https:// github.com/c4pt0r/io_uring-echo-server
Kudos to @ngaut, who contributed the original idea.