[
https://issues.apache.org/jira/browse/TS-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139593#comment-14139593
]
Alexey Ivanov commented on TS-3080:
-----------------------------------
Bottleneck seems to manifest itself if:
1) we are around ~1k handshakes/sec.
2) we have huge session cache side - 300000 entries
It manifests itself in all NET threads stuck inside [SSL_CTX_flush_sessions].
Which is quite logical since it's going through the list of sessions applying
timeout function to each of them while holding a lock:
{code}
lh_SSL_SESSION_doall_arg(tp.cache, LHASH_DOALL_ARG_FN(timeout),
TIMEOUT_PARAM, &tp);
{code}
So we either need to reduce number of elements in cache which will make it
useless or write our own implementation (preferably) using CK and
{{SSL_CTX_sess_set_\{new,get,remove\}_cb}} callbacks.
(That's how nginx done it, though nginx still allows using built-in openssl
cache, though it is slow and causes memory fragmentation
[nginx#ssl_session_cache])
[SSL_CTX_flush_sessions]
https://github.com/openssl/openssl/blob/master/ssl/ssl_sess.c#L964
[nginx#ssl_session_cache]
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache
> OpenSSL implementation of TLS session cache is very slow.
> ---------------------------------------------------------
>
> Key: TS-3080
> URL: https://issues.apache.org/jira/browse/TS-3080
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Fix For: 5.2.0
>
>
> The OpenSSL implementation of TLS session caching is very slow, we attempted
> to use it and it's locking and blows up at only a few hundred QPS. I'm going
> to develop a new TLS session cache in TS that is more performant under
> highload.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)