We have an outbound path we are trying to use that is latency sensitive. The remote site is about 100ms away, so the TLS handshake is quickly adding to the total time for a transaction. Our idea was to use haproxy as an egress controller to help reuse these connections, so we didn’t have to do a seperate handshake for each. The remote side does not yet support http\2, but they are working on it.
This seems to work great when things are busy. however, when there is little activity (a transaction every few min) each one creates a new connection. It does not seem to keep a ‘minimum’ number of open and ready connections.
We have a backend configured for haproxy 2.6 like so: (for testing, i’m not verifing SSL, but would for production)
backend outgoing-test
log global
#using examples from https://www.haproxy.com/user-spotlight-series/haproxy-as-egress-controller
timeout http-request 50s
timeout http-keep-alive 30s
timeout queue 0s
http-request set-header Host api.example.com
http-request replace-path /outgoing-test/(.*) /\1
#should only use 20 connections max
fullconn 20
http-reuse aggressive
server outgoing_test api.example.com:443 resolvers mydns maxconn 20 sni str(api.example.com) ssl verify none alpn h2,http/1.1 pool-purge-delay 30m
Is there a way to have haproxy persist a minimum number of connections with http keepalives, so its ‘ready’ when needed?
We use haproxy heavily for inbound, so it was natural to try with this to start… but if this is not realy what its for, can someone recommend a tool to use for outbound that could help? I guess conceptually, i am looking to do something similar to what PGBouncer does for Postgres connections, but for outbound TLS to get around the latency and time of using new connections.