Django Sessions

By : Dave
Source: Stackoverflow.com
Question!

I'm looking at sessions in Django, and by default they are stored in the database. What are the benefits of filesystem and cache sessions and when should I use them?

By : Dave


Answers

I'm no Django expert, so this answer is about session stores generally. Downvote if I'm wrong.

Performance and Scalability

Choice of session store has an effect on performance and scalability. This should only be a big problem if you have a very popular application.

Both database and filesystem session stores are (usually) backed by disks so you can have a lot of sessions cheaply (because disks are cheap), but requests will often have to wait for the data to be read (because disks are slow). Memcached sessions use RAM, so will cost more to support the same number of concurrent sessions (because RAM is expensive), but may be faster (because RAM is fast).

Filesystem sessions are tied to the box where your application is running, so you can't load balance between multiple application servers if your site gets huge. Database and memcached sessions let you have multiple application servers talking to a shared session store.

Simplicity

Choice of session store will also impact how easy it is to deploy your site. Changing away from the default will cost some complexity. Memcached and RDBMSs both have their own complexities, but your application is probably going to be using an RDBMS anyway.

Unless you have a very popular application, simplicity should be the larger concern.

Bonus

Another approach is to store session data in cookies (all of it, not just an ID). This has the advantage that the session store automatically scales with the number of users, but it has disadvantages too. You (or your framework) need to be careful to stop users forging session data. You also need to keep each session small because the whole thing will be sent with every request.



As of Django 1.1 you can use the cached_db session back end.

This stores the session in the cache (only use with memcached), and writes it back to the DB. If it has fallen out of the cache, it will be read from the DB.

Although this is slower than just using memcached for storing the session, it adds persistence to the session.

For more information, see: Django Docs: Using Cached Sessions



If the database have a DBA that isn't you, you may not be allowed to use a database-backed session (it being a front-end matter only). Until django supports easily merging data from several databases, so that you can have frontend-specific stuff like sessions and user-messages (the messages in django.contrib.auth are also stored in the db) in a separate db, you need to keep this in mind.

By : kaleissin


This video can help you solving your question :)
By: admin