Vandaag beantwoorden we de nieuwsgierigheid over of request.session.get() in Django prestaties kan beïnvloeden? 🎯

Als je werkt met Django, roep je vaak request.session.get('key_name') aan, toch? Maar plotseling kwam deze gedachte bij me op.

"Als sessies uiteindelijk in de database worden opgeslagen, veroorzaakt het aanroepen van request.session.get() dan bij elke aanroep een DB-query?"

"Of heeft Django iets slim gedaan, waardoor er geen extra query's worden uitgevoerd?"

Om deze nieuwsgierigheid te bevredigen, heb ik de diepten van de SessionMiddleware broncode van Django doorgespit en dit door experimenten bevestigd. 🚀

1️⃣ Hoe wordt request.session in Django aangemaakt?

Laten we bekijken wanneer Django de sessie laadt bij het maken van het request-object.

Django session management process

Gewoonlijk halen we de sessiegegevens op in de view functie zoals dit.

session_username = request.session.get('username')

Maar als request.session.get('username') elke keer dat het wordt aangesproken een DB-query uitvoert, kan dit aanzienlijke gevolgen hebben voor de prestaties, toch?

🔍 Laten we een kijkje nemen binnen Django!

Eigenlijk laadt Django via de middleware genaamd SessionMiddleware de sessiegegevens vooraf wanneer er een verzoek binnenkomt. In dit proces wordt de DB-query slechts één keer uitgevoerd, en daarna worden de sessiegegevens in het request-object behouden.

Als we de code van Django's SessionMiddleware bekijken, zien we de volgende verwerking plaatsvinden.

class SessionMiddleware(MiddlewareMixin):
    def process_request(self, request):
        session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
        request.session = self.SessionStore(session_key)

📌 Belangrijke punten!

  • ✅ We halen de sessiesleutel (session_key) uit request.COOKIES.
  • ✅ Door self.SessionStore(session_key) aan te roepen, worden de sessiegegevens slechts één keer uit de DB gehaald en in request.session opgeslagen.
  • ✅ Dit betekent dat zelfs als je meerdere keren request.session.get() aanroept in de view, er geen extra DB-query's worden uitgevoerd! 🎯

2️⃣ Veroorzaakt request.session.get() DB-query's?

Laten we terugkeren naar de kernvraag.

"Veroorzaakt het aanroepen van request.session.get('username') in de view een DB-query?"

🚀 Om het kort te zeggen, het aanroepen van request.session.get() veroorzaakt geen extra DB-query's.

De reden is eenvoudig.
✔ Django laadt de sessiegegevens één keer wanneer het verzoek binnenkomt en slaat deze op in request.session.
✔ Het aanroepen van request.session.get() haalt gewoon de al in het geheugen geladen gegevens op, dus er is geen extra DB-zoekopdracht nodig.

Zelfs het moment waarop een sessie in de DB wordt opgevraagd, gebeurt slechts één keer bij de aanvang van het verzoek. De SQL-query die hierbij wordt uitgevoerd, is als volgt.

SELECT session_data FROM django_session WHERE session_key = 'xyz123' LIMIT 1;

 Dus, ✅ zelfs als je meerdere keren request.session.get() in de view aanroept, voert Django geen extra DB-query's uit!
      ✅ Het ophalen van gegevens uit de DB gebeurt slechts eenmaal aan het begin van het verzoek!

3️⃣ Worden er ook query's uitgevoerd bij het gebruik van sessiegegevens in de sjabloon?

"Als ik sessiegegevens in de view opvraag en deze naar de sjabloon doorgeef, worden er dan extra DB-query's uitgevoerd wanneer ik ze in de sjabloon gebruik?"

def my_view(request):
    session_username = request.session.get('username')  # DB-oproep? ❌
    return render(request, 'my_template.html', {'session_username': session_username})

En stel je voor dat je het in de sjabloon gebruikt op deze manier.

<p>Ingelogd als: {{ session_username }}</p>

In dit geval worden er ook geen extra DB-query's uitgevoerd!

session_username is al een waarde die uit request.session is gehaald, dus Django hoeft geen extra DB-query uit te voeren bij het doorgeven aan de sjabloon.

✔ Django beheert request.session als geheugen-cache, zodat je het ook veilig in de sjabloon kunt gebruiken.


4️⃣ Worden wijzigingen in sessiegegevens in de DB opgeslagen?

"Wat als ik de gegevens verander met request.session['username'] = 'new_value'?"

🚀 In dit geval worden de wijzigingen in de DB opgeslagen en worden er extra DB-query's uitgevoerd!

request.session['username'] = 'new_value'

zal Django de gewijzigde sessiegegevens in de DB opslaan wanneer het het antwoord verstuurt. De SQL-query die hierbij wordt uitgevoerd, is als volgt.

UPDATE django_session SET session_data = 'new_value' WHERE session_key = 'xyz123';

Het lezen van sessiegegevens veroorzaakt geen DB-query's, maar als je ze wijzigt, voert Django een query in de DB uit om deze op te slaan.


5️⃣ Verschillen afhankelijk van de manier van opslaan van sessies (backend)

In Django kun je de manier van sessieopslag (backend) wijzigen. Zorg ervoor dat je op de hoogte bent van hoe de query's kunnen verschillen, afhankelijk van de backend.

Sessie Backend Beschrijving Veroorzaakt DB-query's?
django.contrib.sessions.backends.db Standaard DB-gebaseerde sessie ✅ Eén keer bij verzoek
django.contrib.sessions.backends.cache Cache-gebaseerde sessie (Redis, Memcached) ❌ Geen DB-query's
django.contrib.sessions.backends.cached_db Cache + DB sessie (DB-oproep als er geen cache is) 🚀 Uitgevoerd als het niet in de cache zit
django.contrib.sessions.backends.signed_cookies Cookie-gebaseerde sessie ❌ Geen DB-query's

🚀 Dus, als je de cache of signed_cookies backend gebruikt, kun je sessies zonder DB-query's ophalen. ✔ Het overwegen van CACHED_DB_SESSION is ook een goede optie als prestaties belangrijk zijn.


🎯 Conclusie

  • ✅ Django laadt de sessiegegevens vooraf via SessionMiddleware bij de aanvang van het verzoek en slaat deze op in het request.session object.
  • ✅ Daarom genereert het aanroepen van request.session.get('username') geen extra DB-query's.
  • Er worden geen extra DB-query's uitgevoerd wanneer sessiegegevens in de sjabloon worden gebruikt.
  • ✅ Echter, als de sessiewaarden worden gewijzigd, slaat Django de gewijzigde gegevens op in de DB wanneer het antwoord verzonden wordt.
  • ✅ Afhankelijk van de configuratie van Django's sessie-backend kan de frequentie van query's verschillen, dus het gebruik van cache-gebaseerde (cache of cached_db) kan de belasting op de DB verminderen.

🔥 Volgende aflevering: Wanneer verdwijnt het request object?

Wanneer verdwijnt het request object?

  • Blijft het geheugen gebruiken, zelfs als de aanvraag is beëindigd?

  • Wordt het automatisch door het systeem schoongemaakt of moeten we het zelf opruimen?

🚀 In de volgende aflevering zullen we het leven en geheugenbeheer van het request object in Django onderzoeken! Blijf kijken! 😃