There is a call to is_modified and to stat functions from inside a global lock each time an SSL connection is created. stat() blocks thread unless called via an asynchronous tactic (like in a fork).
It's a major problem for systems with slow disks, lot's of new connections, lots of cores, that are using fast_tls.
is_modified should be called on the erlang side, not inside the NIF. We should limit how often we call it.
I.e. if we have a burst of 10k incoming connections in 5 seconds, we should call is_modified once.
If we don't have incoming connections, we don't need to call it.
Than we can command to NIF to reload an updated file explicitly.
There should be API to list cached certs and info about them (for testing and introspection).
We can also read certs from erlang into binaries.
We can use NIF resources for transfering SSL_CTX-s on the erlang side and manage them in erlang.
There is a call to is_modified and to stat functions from inside a global lock each time an SSL connection is created. stat() blocks thread unless called via an asynchronous tactic (like in a fork).
It's a major problem for systems with slow disks, lot's of new connections, lots of cores, that are using fast_tls.
Function in question https://github.com/processone/fast_tls/blob/1.0.20/c_src/fast_tls.c#L566
Proposed ideas
is_modified should be called on the erlang side, not inside the NIF. We should limit how often we call it. I.e. if we have a burst of 10k incoming connections in 5 seconds, we should call is_modified once. If we don't have incoming connections, we don't need to call it.
Than we can command to NIF to reload an updated file explicitly.
There should be API to list cached certs and info about them (for testing and introspection). We can also read certs from erlang into binaries.
We can use NIF resources for transfering SSL_CTX-s on the erlang side and manage them in erlang.