Fast Session Handler using MongoDB as the store.

on localhost (Rackspace 256Meg Cloud Server) benchmarks are as follows.

Server Software:        nginx/0.7.67
Server Hostname:        auth.sysdom.com
Server Port:            80

Document Path:          /mongodb_session.php
Document Length:        176 bytes

Concurrency Level:      100
Time taken for tests:   0.866 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      581000 bytes
HTML transferred:       176000 bytes
Requests per second:    1154.58 [#/sec] (mean)
Time per request:       86.612 [ms] (mean)
Time per request:       0.866 [ms] (mean, across all concurrent requests)
Transfer rate:          655.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.6      0      15
Processing:    13   80  21.1     86     120
Waiting:       12   80  21.2     86     119
Total:         22   81  18.8     86     120

Percentage of the requests served within a certain time (ms)
  50%     86
  66%     90
  75%     95
  80%     97
  90%    103
  95%    106
  98%    110
  99%    113
 100%    120 (longest request)

At over 1000 requests/second this shouldn't be the bottleneck in the application unless mongo is really bogged down (in which case shard it already)

A key is required on expiry otherwise it is slow doing a garbage collection run.

I personally am disabling the garbage collection within my app and running a seperate task every so often to clean them up.

As a comparison, here are results of the benchmark done across the atlantic... approx 100ms latency...

Server Software:        nginx/0.7.67
Server Hostname:        auth.sysdom.com
Server Port:            80

Document Path:          /mongodb_session.php
Document Length:        176 bytes

Concurrency Level:      100
Time taken for tests:   2.187 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      581000 bytes
HTML transferred:       176000 bytes
Requests per second:    457.19 [#/sec] (mean)
Time per request:       218.729 [ms] (mean)
Time per request:       2.187 [ms] (mean, across all concurrent requests)
Transfer rate:          259.40 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       90  104  14.3     98     150
Processing:    91   99   8.6     97     149
Waiting:       91   99   8.6     97     149
Total:        182  203  20.9    196     299

Percentage of the requests served within a certain time (ms)
  50%    196
  66%    203
  75%    209
  80%    213
  90%    225
  95%    251
  98%    276
  99%    287
 100%    299 (longest request)

Normal session handlers will lock the session until they can aquire exclusive write access to the session - This has the side-effect of causing pages to pause until a long winded request for the same session id releases the lock... 

We aren't doing that in this handler, but it comes with a trade-off. It is possible for one request to read the session and before the changes are written back another request to read it again... Which can result in data loss.

Request 1 - Read Session
Request 2 - Read Session
Request 2 - Write Session
Request 1 - Write Session (overwriting changes from Request 2)

Obviously this can happen far more easily in AJAX based apps where many requests with sessions enabled can be fired off at the same server at once... what we need is a read-only session... ( see new flag on contructor) :)

If you do really need true consistancy, store it in the MongoDB datastore with its atomic ($set, $inc $push etc) operators - it is plenty fast enough for most requirements (well over 3000 requests a second (fetch, create if not exist, write) just in this session handler example code)