request.session.modified vs SESSION_SAVE_EVERY_REQUEST

user_9737374 0
Viewed 482

I understand how these work differently in practice. For example, if I have:

request.session.['cart'].remove('item')

the session won't be saved without explicitly calling request.session.modified = True

or having SESSION_SAVE_EVERY_REQUEST = True in settings.py.

Or I could get around using either by using:

cart = request.session['cart']
cart.remove('item')
request.session['cart'] = cart

My question is if there is any drawback to using SESSION_SAVE_EVERY_REQUEST whether in performance or unintended consequences. I don't see any reason why I wouldn't want to save the session if I modified a value in it.

django-sessions django
1 Answers

(…) if there is any drawback to using SESSION_SAVE_EVERY_REQUEST whether in performance or unintended consequences. I don't see any reason why I wouldn't want to save the session if I modified a value in it.

Well SESSION_SAVE_EVERY_REQUEST will save the session each time. Regardless whether you made hanges, since Django can not (perfectly) detect that. This thus means that at the end of every request, the session will be serialized.

Sessions are stored at the server side. It will set a cookie in the client's browser with the session key, but the data of the session itself is stored at the server side. There are several ways to store sessions, this can be done in e (memory) cache, but also in a file on the filesystem, or in a database. Especially the last two will generate some overhead in terms of filesystem I/O, or database queries. While these operations will likely not be the bottleneck, it is an extra source of queries or disk I/O, and thus will have some implications on performance and probably the price of hosting the application.

user_675790
Related