51478 - Speed up SSL server session cache

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

This enhancement request was formerly bugsplat bug 357218

NSS's SSL server session cache code has always used lseek, read and
write operations on a shared FD to implement the server session cache 
on UNIX.  Because there is no atomic lseek-and-read or lseek-and-write 
operation on most supported unix platforms, it is necessary to surround 
each pair of lseek/read operations and lseek/write operations with a 
lock.  This is not merely a record lock, because all the processes share 
a single fd, and hence a single file pointer.  The addition of this lock 
solved a problem that sometimes caused cache info to be read or written 
to the wrong place in the cache file, but it resulted in slower 
performance for SSL session restart in NSS 2.0.

A much better solution appears to be to memory map the SSLserver 
session cache files.  This eliminates the dependency on lseek, read,
write, and a single file pointer.  It allows the current slow and
somewhat-contentious lock to be replaced with minimally contentious
record locks.  

posix fcntl-style record locks reportedly do not work with memory 
mapped files and reportedly are much slower than certain other kinds 
of locks.  Locks that can be implemented purely in user-level 
(application) code using shared memory (not system calls) would be 
preferrable.  

Posix semaphores are available on SOME unix platforms, but not on 
all supported platforms.  

Note: a partial implementation of this exists for Unix and Windows.

Comment 1

[John G. Myers]

Many systems implement pread() and pwrite(), which remove the need to lock
around the file pointer.  On systems which do not implement those calls, one can
emulate them with the old lock/seek code.

pthread_mutexattr_setpshared() is not available on all platforms.  Berkekey DB
solves this problem by using spinlocks on systems without
pthread_mutexattr_setpshared().

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Changing target to 3.3.  

I definitely want to do this for 3.3.
Once the SSL server session cache is implemented in shared memory
on all platforms, it will then be possible to change it to be
N-way associative (N > 1), which should reduce the incidence of 
cache collisions dramatically.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The new code that uses shared memory instead of lseek and read/write
is now implemented and checked in on the trunk.  In my limited testing
and in the automated nightly performance testing, the server 
performance has been essentially unchanged from before 8-(.

There is, however, one significant advantage of the new code over the 
old code.  I believe this reason is strong enough that it warrants 
the continued use of the new code, even if the performance isn't much
better.  

Because of the "birthday paradox", the old code suffered cache collisions
(two SSL sessions using the same cache slot) even when the cache was less
than half full.  To achieve a reasonable level of cache collisions, it was
necessary to size to cache to have a number of slots that was approximately
the square of the expected number of SSL sessions.  

The new cache is 128-way associative, and when replacing entries in cache
slots, it replaces the oldest entry (in a set of 128) first.  So, the new
cache will not require the enormous oversizing that the old cache did.  
The new code will handle a given number of sessions with a much smaller 
cache than was necessary with the old code.

There is more opportunity for improvement, even with the new code.
So, I am not yet marking this bug as resolved/fixed, but I believe the
largest part of the work is now done.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Changed my mind.  Marking fixed.

Comment 5

[Wan-Teh Chang]

Attachment: Instructions to back out the new SSL server cache code.

Comment 6

[Wan-Teh Chang]

Moved the target to NSS 3.4.