Hi Willy,
>> When it uses the private cache, I would also have to change the
>> configuration to allow ssl sessions over multiple http requests right?
>
> No you don't need to change anymore, what Emeric's patch does is to
> reimplement a hand-crafted spinlock mechanism.
Two slightly unrelated questions:
When we do those kind of workarounds (tcp mode, reconnecting to our own
HTTP(S) frontend), would using unix sockets be more performant (causing
less load) than TCP over the loopback or are there disadvantages?
> I just ran a few tests here and at 4.5k conn/s spread over 4 processes I
> see that the lock is already held about 1% of the time, which is very low
> and does not justify using a syscall to sleep.
Would it be possible to share the SSL cache between two haproxy instances,
via a "peer" like protocol? I think stud had something similar available.
Suppose you have an active/passive setup with VIP failover, starting with
an empty SSL cache after a failover can be a problem.
Regards,
Lukas
