What is a good session store for a single-host Node.js production app?

Question

I\'m using Node\'s Express w/ Connect middleware. Connect\'s memory session store isn\'t fit for production:

Warning: connection.session() Memo         


        

Answer 1

I appreciate that this is an old question, but I came across it while searching for a solution to a similar problem. I had already decided to use memcached for session storage on Linux (with connect-memcached), but I also required the ability to run on Windows. I spent a while trying to find an in-memory session storage for a single-process node app. Redis and Memcached don't appear to be well-supported on Windows, and I didn't want the additional complexity of their installation.

I found session-memory-store in another Stack Overflow thread, which looks good but significantly increased the size of my dependencies.

Finally, I found memorystore in the documentation for express-session. I had missed it originally due to the similarly of its name to the default MemoryStore, but it's exactly what I was looking for:

express-session full featured MemoryStore module without leaks!

I'm now using connect-memcached when running in a cluster (on Linux only), and memorystore when running a single process (on Linux or Windows).

I thought it worth posting this as another answer, just in case anyone else makes the mistake of missing memorystore as I initially did.

Answer 2

I've gone with a MongoDB session store using connect-mongo.

Install with npm install connect-mongo and replace the existing MemoryStore with

app.use(express.session({ store: new MongoStore({ db: 'some-database' }) }));

It manages the database side of sessions automatically.

Answer 3

Spent the day looking into this. Here are the options I've discovered. Requests/second are performed via ab -n 100000 -c 1 http://127.0.0.1:9778/ on my local machine.

• no sessions - fast (438 req/sec)
• cookieSession: requires no external service, minor speed impact (311 req/sec) - fastest, sessions will expire with the cookie (customised by maxAge)
• connect-redis: requires redis server, large speed impact (4 req/sec with redis2go and redisgreen) - faster than mongo, sessions will be deleted after a while (customised by ttl)
• connect-mongo - requires mongodb server, large speed impact (2 req/sec with mongohq) - slower than redis, requires manual clear_interval to be set to cleanup sessions

Here is the coffeescript I used for cookieSession:

server.use express.cookieSession({
    secret: appConfig.site.salt
    cookie: maxAge: 1000*60*60
})

Here is the coffeescript I use for redis:

RedisSessionStore ?= require('connect-redis')(express)
redisSessionStore ?= new RedisSessionStore(
    host: appConfig.databaseRedis.host
    port: appConfig.databaseRedis.port
    db: appConfig.databaseRedis.username
    pass: appConfig.databaseRedis.password
    no_ready_check: true
    ttl: 60*60  # hour
)
server.use express.session({
    secret: appConfig.site.salt
    cookie: maxAge: 1000*60*60
    store: redisSessionStore
})

Here is my coffeescript for mongo:

server.use express.session({
    secret: appConfig.site.salt
    cookie:
        maxAge: 100*60*60
    store: new MongoSessionStore({
        db: appConfig.database.name
        host: appConfig.database.host
        port: appConfig.database.port
        username: appConfig.database.username
        password: appConfig.database.password
        auto_reconnect: appConfig.database.serverOptions.auto_reconnect
        clear_interval: 60*60  # hour
    })
})

Now of course, the remote redis and mongo databases will be slower than their local equivalents. I just couldn't get the local equivalents working, especially considering the installation and maintenance time for me was far more than what I was willing to invest when compared with hosted remote alternatives, something I feel is true for others too hence why these hosted remote database services exist in the first place!

For local database benhmarks, see @Mustafa's answer.

Happy for someone to edit this answer to add their local database benchmarks to the mix.

Answer 4

Another good option is memcached. The session states are lost if memcached is restarted, but there is virtually never any reason to do that. You can leave the cache running all the time even when you restart your app server. Access to the session data is virtually instantaneous and memcached will run happily with whatever (appropriate) amount of memory you give it. And I've never seen memcached crash (on Linux).

https://github.com/elbart/node-memcache

Things to keep in mind about memcached generally:

• Never have whitespace in your cache keys
• Be aware that there is a maximum cache key length, including any namespace prefix you might use. If your cache key is too long, use a 1-way hash of it instead.

Neither of these should be an issue with session storage; just with generalized caching.

Answer 5

I'm just exploring node.js myself, but if you don't need to store a lot of information in the session object -- you might want to explore secure cookies.

Secure cookies store session information as part of the cookie that the browser stores and forwards with each request. They are encrypted to prevent a user from forging a valid cookie.

The advantage is that you don't have to maintain state at the server -- this solution scales well and is simple to implement.

The disadvantage is that you can only store up to about 4KB and that data gets sent to the server on every request (But you can have multiple fictitious domains pointing at your server so you don't impose that baggage on publicly visible static content, for example).

Searching the web it seems like there are at least two implementations of secure cookies for node.js. Not sure how production ready they are, though:

https://github.com/benadida/node-client-sessions/blob/master/lib/client-sessions.js

https://github.com/caolan/cookie-sessions

Answer 6

Check out my benchmarks at https://github.com/llambda/express-session-benchmarks showing comparisons of different session implementations.