[erlang-questions] ssl_session_cache: trouble + questions

[Danil Zagoskin]

Hi!

Recently our servers started to consume lots of SYS CPU.
Inside a VM top processes (by reductions per second) were ssl session
validators.
Most popular current function in runnable processes was
calendar:datetime_to_gregorian_seconds/2.
Also gproc was very slow (it uses ETS).

According to `ets:i().` the largest ETS table was:
    49178           server_ssl_otp_session_cache ordered_set 5015080
305919839 ssl_manager

We have worked around the problem by using lower session_lifetime.

But reading the code I came to these questions:
  - The cache is `ordered_set` type which has logarithmic access time. Does
it have to be `ordered_set`, not just `set` (with constant access time)?
  - There is no protection agains running multiple validators. This leads
to many processes accessing single table and doing the same work. This
seems to greatly increase SYS CPU usage and slowdown in other ETS tables.
Should we skip new validator start if previous one is still running?
  - ssl_session:valid_session is called for every session in cache and
calls `calendar:datetime_to_gregorian_seconds({date(), time()})` itself.
Should we use `erlang:monotonic_time(seconds)` everywhere instead? Or maybe
we should pre-calculate minimal allowed timestamp to avoid extra
arithmetics?


-- 
Danil Zagoskin | z@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151208/0fbc6981/attachment.htm>