On 06/12/2014 10:48 PM, Nathan Scott wrote:
----- 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. ;)
While we can certainly try to avoid these calls until absolutely
necessary, they are unfortunately both required for a server
accepting secure connections. NSS_init() obviously, but
unfortunately, also SSL_ConfigServerSessionIDCache(). See the
following from the MDN site:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslfnc.html#__SSL_ConfigServerSessionIDCache_
"If you are writing an application that will use SSL
sockets that handshake as a server, you must call
SSL_ConfigServerSessionIDCache to configure additional session
caches for server sessions."
So I think the best we can do on this one is to find out what the
minimum cache size that we can get away with is. You're research
seems to indicate that 1 entry works, but there could possibly be
performance implications (the usual purpose of a cache).
I'm still puzzled a bit by the urgency of this, even for teensy tiny
boxen. The cache size reduction will help, but once a secure
connection is made, then the NSS_init() and
SSL_ConfigServerSessionIDCache() calls must be made and the RSS will
grow at least temporarily.
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).
*nod*
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).
Yeah, stap-serverd accepts only secure connections. There's probably
no point to starting it without NSS, but the SSL cache size could
probably be tweaked.
Dave
|
|