----- Original Message -----
> ----- Original Message -----
> > > [ ... ]
> > For the NSS/NSPR/SSL layers, I think that the main complication, for
> > servers, is that, at the time a socket is created for accepting a
> > connection, it isn't known whether that socket will need to be secure.
>
> Yep.
> [...]
> I'll keep digging & send out some more details.
More details:
Calling __pmInitSecureSockets() is the major issue, though unfortunately
its not just one of the setup calls therein that blows us out. However,
even without this call, we still incur >100% increase in RSS (of ~1.6M).
In absolute terms, is getting more in the ballpark of something we could
consider 'OK-ish' (maybe; lets see what others think I guess - I'd still
be disappointed with that level of bloat, but maybe I can get over that).
Within __pmInitSecureSockets, the two biggest problems are initialising
NSS - note this one affects all the clients too :( - and the SSL session
cache setup. The former is an immediate bump up to the ~5/6MB RSS mark.
The latter sends us to ~10/11MB.
NSS init first - looked into the space optimize flag Frank mentioned; it
appears to be set by default for both the client & server init calls we
made (goodness, I wonder what not setting that flag would end up doing!).
Digging through the mozilla hg tree, I'm not seeing any other techniques
we can use to quickly tame it - it does a ton of allocations left, right
and centre - avoidance on our part seems the best strategy?
Secondly, the SSL session cache setup - we call that with default args;
the first arg (we give zero, which means "use defaults") gets translated
within NSS SSL code to mean "give me a session cache with 10000 entries,
via DEF_SID_CACHE_ENTRIES (ssl/sslsnce.c). Experimenting with this, we
can use a mimimal setting of "1" here, but that only brings us down to
a ~8MB RSS size (SID_CACHE_ENTRIES_PER_SET and SID_ALIGNMENT come into
play for all requested settings). Looking in this source file, there's
several more caches in there that we allocate at this time - there's
a certificate cache, key cache, and a server name cache. Making our
code not call in here at all by default seems like a good option. ;)
The fact that client tools were being bloated out too was lost on me
before doing this digging (not to mention that their startup times are
being permanently burdened with full NSS/SSL setup - so CPU & IO costs
in there too we could defer) ... guess we should keep that in mind when
tackling the server side (your magic-fd-upgrade mechanism, and a secure
ops vectore vs native ops vector kind-of-approach could suit both).
cheers.
ps: stap-server has all these issues too I'd imagine - does that run in
secure mode, always? I guess it does, since thats kinda the point? It
would be delightful if we could get wins there, as a result of looking
into it for PCP.
(Ah! - the cache setting size could help? /me fires up a stap-serverd
.... hohum, ~10MB RSS, sounds familiar! yes, the SID cache size setting
will reduce that - finding APIs to reach nss/lib/ssl/sslsnce.c:InitCache
will give further control over cert and server name cache sizes too).
--
Nathan
|