All users were logged out of Bugzilla on October 13th, 2018
774 bytes, text/plain
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.
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().
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.
Target Milestone: 3.2 → 3.3
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.
Changed my mind. Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Moved the target to NSS 3.4.
Target Milestone: 3.3 → 3.4
You need to log in before you can comment on or make changes to this bug.