Hi Dave,
----- Original Message -----
> [...]
> 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).
Yep. 10,000 entries seems over the top for a perf tool ... we should
pick a number that makes more sense (100 sessions?) and go with that.
> I'm still puzzled a bit by the urgency of this, even for teensy tiny
> boxen. The cache size reduction will help, [...]
Oh, not super urgent (ie. we shouldn't hold up the WIP release for it);
didn't mean to give that impression, but it needs to be tackled soonish
since we caused this regression (& we know what it is). Mainly wanted
to make sure its understood that it is indeed important to tackle - and
to discuss *how* to tackle it (and, yeah, sooner the better I reckon).
Memory footprint is also a metric people will use when considering PCP,
and/or comparing to other similar tools.
If we stack it up against the other things we're working on - this will
improve things for practically every current PCP user and its clearly a
regression... so while all the feature work is great, we cannot just be
accepting of this kind of collateral damage from those features. It's
a slippery slope toward mediocrity.
> 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.
Yep - even growing permanently in this case is fine - we don't really
need to focus on this aspect since the vast majority of installations
make no encrypted connections at all.
cheers.
--
Nathan
|