Django Sessions

stemmer
37

Jeg ser på økter i Django, og som standard de er lagret i databasen. Hva er fordelene med filsystem og cache økter, og når bør jeg bruke dem?

Publisert på 08/09/2008 klokken 20:16
kilden bruker
På andre språk...                            


5 svar

stemmer
25

Filsystemet backend er bare verdt å se på hvis du ikke kommer til å bruke en database for noen annen del av systemet. Hvis du bruker en database deretter filsystemet backend har ingenting å anbefale den.

Den memcache backend er mye raskere enn database backend, men du risikerer en sesjon blir renset og noen av dine session data går tapt.

Hvis du er en veldig, veldig høy trafikk nettsted og kode nøye, slik at du kan takle å miste en økt deretter bruke memcache. Hvis du ikke bruker en database bruker filsystemet cache, men standard database backend er den beste, sikreste og enkleste alternativet i nesten alle tilfeller.

Svarte 08/09/2008 kl. 20:58
kilden bruker

stemmer
19

Jeg er ingen Django ekspert, så dette svaret er om økt butikker generelt. Downvote hvis jeg tar feil.

Ytelse og skalerbarhet

Valget av økten butikken har en effekt på ytelse og skalerbarhet. Dette bør bare være et stort problem hvis du har en veldig populært program.

Både database og filsystem session butikker er (vanligvis) støttet av disker slik at du kan ha mye økter billig (fordi diskene er billig), men forespørsler vil ofte må vente på dataene som skal leses (fordi diskene er treg). Memcached økter bruke RAM, så vil koste mer for å støtte det samme antall samtidige sesjoner (fordi RAM er dyrt), men kan være raskere (fordi RAM er rask).

Filsystem økter er knyttet til boksen hvor programmet kjører, så du kan ikke laste balanse mellom flere programservere hvis området blir enorme. Database og memcached økter la deg ha flere programservere snakker med en felles sesjon butikken.

enkelhet

Valget av økten butikken vil også påvirke hvor lett det er å distribuere nettstedet ditt. Endring fra standard vil koste noen kompleksitet. Memcached og RDBMSs begge har sine egne kompleksiteten, men søknaden er trolig kommer til å bruke en RDBMS uansett.

Med mindre du har en svært populært program, bør enkelhet være større bekymring.

Bonus

En annen tilnærming er å lagre session data i cookies (alle av det, ikke bare en ID). Dette har den fordelen at økten butikken skalerer automatisk med antall brukere, men det har ulemper også. Du (eller ramme) må være forsiktig med å stoppe brukere smiing sesjonsdata. Du må også holde hver økt liten fordi det hele vil bli sendt med hver forespørsel.

Svarte 09/09/2008 kl. 10:11
kilden bruker

stemmer
9

Per Django 1.1 kan du bruke cached_db økten bakenden.

Dette lagrer økt i cache (bruk kun med memcached), og skriver det tilbake til DB. Hvis det har falt ut av cache, vil det bli lest fra DB.

Selv om dette er tregere enn bare å bruke memcached for lagring av økten, legger det utholdenhet til økten.

For mer informasjon, se: Django Docs: bruke bufret Sessions

Svarte 21/12/2009 kl. 11:21
kilden bruker

stemmer
3

En ting som må vurderes når du velger session backend er "hvor ofte session data er endret"? Selv områder med moderat trafikk vil lide hvis session data er endret på hver forespørsel, gjør mange database turer å lagre og hente data.

I min forrige jobb brukte vi memcache som session backend eksklusivt og det fungerte veldig bra. Vår administrative teamet setter virkelig stor innsats i å gjøre to spesielle memcached tilfeller stabile som en stein, men etter litt tvinne med første oppsettet, hadde vi ikke har noen avbrudd av sesjons backends operasjoner.

Svarte 19/09/2008 kl. 08:20
kilden bruker

stemmer
1

Hvis databasen har en DBA som ikke er deg, kan du ikke få lov til å bruke en database-støttet økt (det er en front-end saken bare). Inntil django støtter lett å slå sammen data fra flere databaser, slik at du kan ha frontend-spesifikke ting som økter og bruker-meldinger (meldinger i django.contrib.auth blir også lagret i db) i en egen db, må du holde dette i tankene.

Svarte 28/11/2008 kl. 15:34
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more