[ 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)