I faced a performance issue of high CPU usage in a service backed by Vault storage.
The service is processing about 300 requests per second leading to the same or more amount of reads to the Vault cluster.
Profiling shows that most of the CPU time (>80%) service is spending in SSL connection handshake code. It also affects a Vault server load.
Seems that a new connection is opened on each request.
Moreover, tests show that the old connection isn't closed (disconnected) right after usage and persisted in the keep-alive cache by JVM.
The idea is to build and keep an SSLSocketFactory instance with a SslConfig/VaultConfig instance. So the same SSLSocketFactory can be passed to a Rest instance on every operation based on the same config.
It requires additional configuration on every Rest instance creation so I fixed this only for the Logical class yet.
I would like to discuss this solution and prepare a PR if it will be found suitable.
Hi
I faced a performance issue of high CPU usage in a service backed by Vault storage. The service is processing about 300 requests per second leading to the same or more amount of reads to the Vault cluster.
Profiling shows that most of the CPU time (>80%) service is spending in SSL connection handshake code. It also affects a Vault server load.
Seems that a new connection is opened on each request. Moreover, tests show that the old connection isn't closed (disconnected) right after usage and persisted in the keep-alive cache by JVM.
Java HTTP implementation supports persistent connections out of the box https://docs.oracle.com/javase/7/docs/technotes/guides/net/http-keepalive.html
But for HTTPS the consequent requests should also use the same instance of SSLSocketFactory.
Sample fixes are here https://github.com/BetterCloud/vault-java-driver/compare/master...samfrown:ssl-connections-reusage
The idea is to build and keep an SSLSocketFactory instance with a SslConfig/VaultConfig instance. So the same SSLSocketFactory can be passed to a Rest instance on every operation based on the same config.
It requires additional configuration on every Rest instance creation so I fixed this only for the Logical class yet.
I would like to discuss this solution and prepare a PR if it will be found suitable.