Clarify the shared cache

[theflow]

it would be really helpful if the purpose and workings of the shared cache would be explained a bit more in the README. I'm also unclear if the shared cache is only useful for multi-host deployments or also when running stud with more than 1 worker process.

When running with stud with "-n 2", should I compile it with USE_SHARED_CACHE enabled or not?

Cheers,
Florian

[EmericBr]

Stud use multiple subprocess and bind them on logical CPUs (cores). Those subprocess are created using fork or clone and are not threads, so they don't share the same memory space. Consequently they don't share the same internal session cache of the openssl library. It causes session to be renegotiate each time next request switch on an other process with a significant performance cost. The shared cache feature add an additional cache in a shared memory, and if a process don't find the session in the openssl internal cache the session is searched into the shared cache. The share entry mecanism for multiple host was introduced later to allow multiple host to share their local shared cache entries to minimize renegotiation in a case of a multiple host load balanced deployments of stud.

Notice that newest clients use a TLS ticket extension, server ( here stud ) provide a kind of cookie, reposted by the client into each next requests, it contains all ssl session informations and set the session cache useless. Openssl used a localy randomized shared secret to protect those tickets, and is not shareable between multiple hosts. Vincent Bernat working on this.

So actually, use shared cache is usefull on mono-host-multi-core deployments if you want to avoid session renegotitation for clients which not supports TLS tickets extension and on multi-host-deployments it you want to avoid renegotiation for clients switching hosts (the feature disables TLS tickets extension on server site to force usage of shared cache).