Estamos trabajando en una nueva aplicación, usando como no, nuestro lenguaje y framework favoritos (Python / Django). La aplicación es un B2B de logística y en el modelo de datos tenemos como base una empresa que cuenta con usuarios, que son los que operan.
En un primer momento, usamos las sesiones de Django, definimos el backend de estas contra cache (memcache), pero aún así, en cada petición, la aplicación realizaba la consulta de los datos del usuario y de la empresa. Ahorrabamos las consultas a la tabla sesiones, (backend de sesiones por defecto).
Pero aún podíamos ir un paso mas allá. Tanto los datos del usuario como los datos de la empresa, son más o menos estables, hay pocos cambios, con lo que eran objetos que debían de estar en caché. Así liberabamos mysql, para las consultas de las distintas vistas.
Indagando un poquito en los backends de autentificación, nos dimos cuenta, que el AuthenticationMiddleware, era el encargado de cargar los datos del usuario en la sessión. Si poníamos este en cache de ram, nos ahorrabamos un par de querys por vista.
Buscando un poco, encontramos este backend, que era justamente lo que nos interesaba y además permitía añadir vía un preprocesor, un callable que adjuntabas, agregar información a la sesión de memcache. (Cached Auth Preprocessor).
Solo quedaba reajustar con signals, la caducidad de cache. Al realizar cambios en la tabla empresa y/o usuario se captura el signal y se limpia la caché.
El resultado final es que al inicio de sesión del usuario los datos de este y de su empresa vinculada, son "guardados" en la cache de RAM, y así todas las páginas vistas ( evidentemente bajo sesión ) se ahorran querys contra la base de datos. Además es interesante pensar este tipo de cosas al desarrolar la aplicación, ya que, luego, cuando tenga que escalar, será fácil trasladar la cache una máquina externa y así ganar peticiones por segundo.
Keywords: django, session, auth, cache