JDB latency performance


Querying with 10 threads. 100k queries per thread
SQL test is done with a web server frontend (JHTTP) and separate SQL-server backend (mySQL 5.7).
JDB test is done with all-in-one JDB with builtin JHTTP and no filesystem (JDB uses disk partition directly without using EXT4)

All servers have 4x CPUs.
The test query returns a small 94bytes response in all tests.
The larger the response data is, the faster the query will be with JDB because JDB is using zero-copy technology. Imaging you are doing queries returning 65kbyte in return. You need a 100gbit connection between frontend and SQL backend just to do this fast.

Note that this is a latency test only because the dataset only contain 1 row. Disk performance is therefore not a part of the test
Latency versus CPU usage ratio is also an important performance factor.

#1 HTTP with keep-alive

JDB

0,19ms latency
18% usermode CPU
20% kernelmode CPU
Latency*CPU: 7,22

SQL

0,40ms latency
13% usermode CPU
14% kernelmode CPU
+ SQL-server (19% CPU)
Latency*CPU: 18,4 (10,8 without SQL-server)

255% JDB performance increase


#2 HTTPS with full keep-alive

JDB

0,21ms latency
20% usermode CPU
21% kernelmode CPU
Latency*CPU: 8,61

SQL

0,445ms latency
14% usermode CPU
15% kernelmode CPU
+ SQL-server (19% CPU)
Latency*CPU: 21,36 (12,9 without SQL-server)

248%  JDB performance increase


#3 HTTPS with full reconnect

JDB

4,34ms latency
76% usermode CPU
5% kernelmode CPU
Latency*CPU: 351,5

SQL

4,7ms latency
76% usermode CPU
5% kernelmode CPU
+ SQL-server (19% CPU)
Latency*CPU: 470 (380,7 without SQL-server)

134% JDB performance increase

Note: A full TLS handshake uses a lot of resources