<div dir="ltr">Hi!<div><br></div><div>Recently our servers started to consume lots of SYS CPU.</div><div>Inside a VM top processes (by reductions per second) were ssl session validators.</div><div>Most popular current function in runnable processes was calendar:datetime_to_gregorian_seconds/2.</div><div>Also gproc was very slow (it uses ETS).<br></div><div><br></div><div>According to `ets:i().` the largest ETS table was:<br></div><div>    49178           server_ssl_otp_session_cache ordered_set 5015080 305919839 ssl_manager</div><div><br></div><div>We have worked around the problem by using lower session_lifetime.</div><div><br></div><div>But reading the code I came to these questions:</div><div>  - 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)?</div><div>  - 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?</div><div>  - 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?</div><div><br></div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div></div></div>