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.
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
) uitrequest.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 hetrequest.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
ofcached_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! 😃
댓글이 없습니다.