How can we close gap on client performance vs blocking sockets?

pgjdbc-ng uses Netty in a client environment and when we compare performance with that of pgjdbc it can be any where from 100% slower (on localhost) to 15% slower (on any remote host).

After extensive investigation and many failed implementations, we’re at a dead end with making it any faster using the currently provided Netty facilities. We desperately want to keep Netty because it makes the implementation drastically simpler but at some point the performance gap needs to be closed.

The mainline driver uses non-blocking sockets and “no threads” which makes it limiting and unable to implement some features of the JDBC specification correctly. Clearly we need to retain the asynchronous nature of the driver and realize that may impose a performance cost above an unthreaded non-blocking implementation; but we need it to be much closer than it is.

FYI, I tried OioSocketChannel and OioEventLoopGroup because the thread-per-connection model seemed promising; realizing they are deprecated. Unfortunately they appear broken in Netty 4. Due to writes being directed to the event loop thread, and the fact that it uses blocking reads with a periodic timeout, the writes are starved until the read time’s out and the event loop thread can process them. I hacked a version that allow writes from any thread but it provides only a small performance improvement (and is a dubious solution given Netty’s requirements).

So, the basic question is… what are we doing wrong and how can we solve this problem? After reading everything available here, on netty.io, on stackoverflow and pretty much any related hit on Google… this is my last hope.

Minimal yet complete reproducer code (or URL to code)

pgjdbc-ng

Netty version

4.1.42

JVM version (e.g. java -version)

8, 9, 10, 11, 13

OS version (e.g. uname -a)

Darwin <hostname>.local 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64

[kdubb]

I’ve created a simple test project that displays the same issue. https://github.com/impossibl/netty-test

TestServer is a simple server that responds to requests by sending a requested amount of data back to the client with an id. TestClient uses Netty to generate & send requests and wait for responses like pgjdbc-ng does. TestBlockingClient uses a Socket to send the request then does blocking reads to read the response, like pgjdbc does.

TestClient: ~5.8s TestBlockingClient: ~3.7s

[kdubb]

@Liyixin95 Apparently I missed this comment many months ago… Yes TestClient is synchronous, like TestBlockingClient is, to show that merely switching between Netty and a blocking socket has a performance penalty.

The actual driver implementation pipelines request whenever possible.