Louis LeBlanc wrote:
>
> Ok, here's what I have so far:
>
> I turned on cacheing during the OpenSSL initialization in my app, then
> created a mechanizm to purge expired sessions every half hour. The
> entire cache is also purged, and stats are logged just before the logs
> are rolled for backup.
>
> I also added to existing signal traps the ability to force the stats
> logging (along with the thread status dump), purge the expired sessions
> (a config refresh) and purge the whole session cache (force a log
> roll).
>
> So it looks like the process grows at a much more controlled rate, and I
> have a very high degree of session reuse (up to 80 connections per
> session on average). However, I am not setting any sessions before
> SSL_connect(). It seems to be doing it on its own. I was under the
> impression this wouldn't happen - I just wanted to test my monitoring
> mechanism.
My bad. I forgot that I had added the following lines prior to
SSL_connect():
if (ssl_ctx->session_cache_head)
if (!SSL_set_session(ssl_con, ssl_ctx->session_cache_head))
log_error("Unable to set SSL session id to most recent used.");
This was only in for the test. I was connecting only to a single
server, so I had a pretty good idea the session reuse would work ok like
this. What happens when I start trying to hit multiple servers,
though? I am still wondering what is the best way to do this. None of
the .../apps/* files seem to focus on this scenario.
>
> The other odd thing, is that even though the number of sessions
> currently in the cache may drop slightly, the size of the process will
> continue to grow. I was under the impression that clearing expired
> sessions from the cache freed the memory allocated for a session.
>
> Any ideas?
TIA
Lou
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
