Comparison with Alternative Libraries
gae-sessions is a fast, lightweight sessions middleware for the Python runtime on Google App Engine (GAE). This page contrasts gae-sessions with other sessions libraries for this platform:
1. Beaker is standalone library which can be used with any WSGI-based web application. Though you can use it on GAE, it cannot use both memcache and the datastore to save sessions. Unfortunately, this means you’re stuck reading from the datastore which is slow and relatively expensive.
2. gaeutilities provides a dictionary-like sessions interface, but gae-sessions performs much better.
3. gmemsess provides a dictionary-like sessions interface. It only stores sessions in memcache, so sessions may be lost at any time. This tradeoff is made to improve performance, but gae-sessions is still faster and it won’t lose your session data. gae-sessions performs reads 100% faster and writes 5%. If you feel a need for speed, then run gae-sessions in memcache-only mode and then writes for large sessions will be even faster.
4. suas is a cookie-only sessions library. It is a fast for small sessions (no datastore interaction) – but not as fast as gae-sessions. suas’ main drawback is that it only stores strings, and it is a bit more difficult to use – your request handler has subclass its request handler. Also, sessions are not automatically started when a value is stored.
Note: gae-sessions, gaeutilities, gmemsess, and suas were each designed specifically for apps running on GAE’s Python runtime.
Summary: gae-sessions is faster and simpler for all session sizes and workloads.
| Feature | gae-sessions | beaker | gaeutilities | gmemsess | suas | Note |
| Secure | Yes | Yes | Yes | Yes | Yes | Each protects against session fixation attacks. They are also secure against session hijacking when used over SSL (without SSL they cannot protect against a man-in-the-middle attack). |
| Speed | Fastest | Medium | Slow | Fast | Fast | gae-sessions is orders of magnitude faster than gaeutilities, and five times as fast as beaker on average. It is also 100% faster than gmemsess on reads and 5% faster on writes (put gae-sessions in memcache-only mode and it gets even faster for large sessions). On small sessions gae-sessions dominates (suas offers good performance on very small sessions too). |
| Supported Value Types | Any | Any | Any | Any | Strings | Most libraries use pickling to store data so retrieved entities and values are exactly the same, and you can store anything that can be pickled. suas only handles strings. |
| Availability | High | High | High | Variable | High | Most libraries persist data to the datastore to ensure the session data is not lost. gmemsess trades off availability by storing data only in memcache which may lose data at any time. |
| WSGI Middleware | Yes | Yes | No | No | No | WSGI middleware is easy to install and can be used with any WSGI-compliant web framework. It also means you don’t have to write any boilerplate code to initialize or save your sessions – with gae-sessions and beaker, these are automatically done as needed. |
| Feature | gae-sessions | beaker | gaeutilities | gmemsess | suas | Note |
| Scales | Yes | Ok | No | Yes | No | gae-sessions can scale to >10,000 of key-value pairs and up to 1MB of data. |
| Session Cleanup | via cronjob | ? | during user requests | n/a | n/a | Using cron reduces user wait time. |
| Lazy Loading | Yes | Yes | No | No | No | gae-sessions only loads data if you read/write it. It adds zero overhead when you don’t use it. |
| Efficient Entity Storage | Yes | No | Yes | No | Doesn’t support entity storage | gae-sessions automatically stores entities using Google’s protobuf encoding. This is much smaller and quicker than pickling. |
| Complexity | 273 lines | 2,249 lines | 1,053 lines | ~39 lines | 427 lines | gae-sessions and gmemsess both lightweight: just 1 small file. The others are bundled with 10-20 files and 1,000+ lines of code, except suas which is only slightly bigger but requires several files to use. Lines of code were counted using David A. Wheeler’s ‘SLOCCount’. |
| Max Session Size | 1MB | limited by performance | limited by performance | 1MB | <16KB | 1MB is more than most need. Others can theoretically store more data, but in practice App Engine ends up throwing a DeadlineExceededError long before gaeutilities gets to 1MB of data. suas is more limited than most because app engine limits header size (and therefore cookie size too). gae-sessions can store tens of thousands of keys and 1MB of data in under a second. |
Summary: gae-sessions is the fastest. Beaker has competitive write times, but is much slower to read. gaeutilities is orders of magnitude slower than both.
Here is a representative selection of the performance data (times are in milliseconds as specified by AppStats “real” time):
| Read Times (milliseconds) | ||||||
| Session Size | gae-sessions |
gae-sessions (memcache-only) |
beaker | gaeutilities | gmemsess | suas |
| Huge: >10,000 values ~ 500KB | 376 | 360 | 938 | error | 1058 | error |
| Large: 100 values ~ 85KB | 58 | 53 | 224 | 8172 | 93 | n/a* |
| Small: 100 values ~ 0.5KB | 2 | 2 | 112 | 5968 | 15 | n/a* |
| Small: 10 values ~ 0.05KB | 1 |
1 |
89 | 160 | 15 | 3 |
| Tiny: 1 integer | 0 | 0 | 78 | 28 | 12 | 1 |
| Write Times (milliseconds) | ||||||
| Session Size | gae-sessions |
gae-sessions (memcache-only) |
beaker | gaeutilities | gmemsess | suas |
| Huge: >10,000 values ~ 500KB | 668 | 546 | 562 | error | 555 | error |
| Large: 100 values ~ 85KB | 170 | 118 | 230 | 16577 | 133 | n/a* |
| Small: 100 values ~ 0.5KB | 3 | 3 | 118 | 12781 | 23 | n/a* |
| Small: 10 values ~ 0.05KB | 2 | 2 | 73 | 1240 | 24 | 5 |
| Tiny: 1 integer | 1 | 1 | 84 | 112 | 22 | 1 |
*n/a because suas does not support entities/objects. It also stores one value per cookie, and browsers typically limit the maximum number of cookies to 20-40 cookies per domain.
The test suite I put together to gather performance numbers is located here.