-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
100 lines (79 loc) · 3.76 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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)