Worker threads vs shared SSL_CTX: handshake latency under concurrent TLS load

A design is being evaluated where an application uses worker threads with libssl/libcrypto, a single process-wide SSL_CTX for configuration, and a separate SSL object per network connection. The goal is to keep TLS configuration immutable and shared while connection state remains per-connection.

OpenSSL 1.1.0+ documents thread safety around the split between shared configuration in SSL_CTX and mutable per-connection state in SSL. The unresolved behavior concerns shared mutable subsystems that are part of the context: server session cache, session ticket keys, OCSP stapling updates, randomness, and OpenSSL 3.x provider and EVP algorithm resolution. These are part of the integration boundary between the application worker model and libssl.

The decision point is whether a single SSL_CTX with per-thread SSL objects is sufficient for concurrent handshakes, or whether per-worker SSL_CTX instances are needed to isolate caches, tickets, and provider state at the cost of memory and duplicated session reuse.

Is session cache and ticket key state inside SSL_CTX contended under concurrent handshakes? Does OpenSSL 3.x provider and EVP fetch introduce per-handshake lookup cost when using a shared context? Should session resumption policy be treated as part of the TLS integration boundary between workers and libssl?