[jahaa]

Ursprungligen postat av freakalis

Jag är lite nyfiken hur skriver man sin egna sessionshanterare?

Kika på http://se2.php.net/manual/sv/functio...ve-handler.php

[kullervo]

Originally posted by freakalis@Mar 30 2006, 14:52
Jag är lite nyfiken hur skriver man sin egna sessionshanterare?

Läs på php.net hur sessions fungerar.

[dotvoid]

Originally posted by kullervo@Mar 28 2006, 13:00
Använder folk PHP's inbyggda session-hanterare till seriösa sajter? Det var länge sen jag ens tänkte på att det faktiskt finns en inbyggd i PHP. Den var kass för 4 år sedan (då jag senast hade med den att göra). Koda en egen istället. Det blir enklare i längden, ger mycket bättre prestanda

Det nog rätt få seriösa utvecklare som inte använder PHP:s inbyggda sessionshanterare. Att själv sätta en cookie via http-headern Set-cookie är i o f s inte några större problem men onödigt. Däremot är det många som skriver egna krokar för lagring eller rensning av sessionsdata.

För bättre prestanda blir det nog ganska sällan med en userland-implementation i PHP än att använda PHP:s inbyggda funktioner som är skrivna i C. Det är bättre att koncentrera sig på sin applikation eller webbplats än att hålla på och bygga grejer som redan finns inbyggt i språket. Dock är det nog viktigt att man ändå "har koll på sina bitar".

Att lagra sessionsdata på fil, i en databas eller i RAM-minnet är en smaksak och beror på den miljö applikationen/webbplatsen körs i. På till exempel en delad unix-server skulle jag nog vara försiktig med att lagra sessionsdata i /tmp som ju ofta är standard.

Enda gången jag ser någon anledning till att inte använda PHP:s inbyggda sessionshantering (med eller utan egna krokar) är om man använder någon produkt eller extension för en single-sign-on-lösning.

[kullervo]

Ursprungligen postat av dotvoid

För bättre prestanda blir det nog ganska sällan med en userland-implementation i PHP än att använda PHP:s inbyggda funktioner som är skrivna i C.

Om man använder sig av sessions så bygger förmodligen sajten på en SQL-databas. Att bryta ut en del av datat (sessionerna) och lägga det separat någon annan stanns är ju bara krångligt och långsamt. Det är som att dela upp alla tabellerna i två databaser för en och samma sajt.

Ursprungligen postat av dotvoid

Att lagra sessionsdata på fil, i en databas eller i RAM-minnet är en smaksak och beror på den miljö applikationen/webbplatsen körs i. På till exempel en delad unix-server skulle jag nog vara försiktig med att lagra sessionsdata i /tmp som ju ofta är standard.

Och vad är då vitsen med att använda PHP's inbyggda sessionhanterare när det är massa jobb att komma runt dess vanliga problem (såsom det där att det läggs fysiskt på disk och dessutom i /tmp)?

En mycket svag punkt för PHP är att den inte finns en standard för hur allt är konfigurerat. Låt oss säga att du har satt upp en LAMP-server konfigurerat så att du klarar mycket trafik med PHP's inbyggda sessionhanterare (dvs. lagrar datan på säkert ställe samt inte på disk). Vad händer då när du plötsligt ska byta server/webbhotell? Då sitter du kanske plötsligt på en mer standard-installation som både är osäker och långsam då den ska ändra datat i 200 sessions per sekund (stackars diskar). Hade det inte varit enklare då att haft en egen sessionhanterare integrerad i sajten? Jopp, det hade det nog.

Och åter igen, det är så mycket enklare att ha all data på samma ställe. Försök plocka ut användarnamnet på alla som är online just nu på en sajt som använder en separat sessionhanterare. Då ska du först ha ut alla användar-ID:n från alla sessioner (hur gör man ens det med PHP's inbyggda?) och sen ska du formulera det till en två mil lång SQL-fråga som läser ut användarnamnet från databasen. Suck och stön vad krångligt och segt.

[dotvoid]

Ursprungligen postat av kullervo

En mycket svag punkt för PHP är att den inte finns en standard för hur allt är konfigurerat ... Hade det inte varit enklare då att haft en egen sessionhanterare integrerad i sajten? Jopp, det hade det nog.

Verkligen inte. Just för att man har så olika behov är flexibilitet viktig. Så mycket jobb är det ju knappast att ändra till exempel /tmp då det ju finns en specifik metod för att ändra det runtime. Om du hanterar 200 sessioner per sekund tror jag inte det är snabbare med en databas än med en filbaserad lösning. Databasen måste också skriva och läsa data till och från disk. Dessutom måste den hantera index osv.

Ursprungligen postat av kullervo

Och åter igen, det är så mycket enklare att ha all data på samma ställe. Försök plocka ut användarnamnet på alla som är online just nu på en sajt som använder en separat sessionhanterare. Då ska du först ha ut alla användar-ID:n från alla sessioner (hur gör man ens det med PHPs inbyggda?) och sen ska du formulera det till en två mil lång SQL-fråga som läser ut användarnamnet från databasen. Suck och stön vad krångligt och segt.

Jag vet inte om det är så krångligt. Man använder sig av PHP:s inbyggda sessionshantering men definierar en egen metod för att spara sessioner genom PHP:s session_set_save_handler(). I din egendefinierade metod för att spara sessionen är det lätt att plocka ut exempelvis ett användarid och koppla sessionsdata till detta och spara både sessionsdata och användarreferenser i en databas på det vis man vill.

Finns ingen anledning att skapa en egen sessionshantering när det finns så bra möjligheter att integrera PHP:s sessionshantering med sin egen kod.

Jag misstänker att vi är helt överens egentligen. Är det så att det du kallar för "egen sessionshanterare" egentligen bara är dina userland-funktioner du registrerar via session_set_save_handler()? I så fall missförstod jag nog din första post.

När jag läser "egen sessionshantering" så läser jag det som att man ersätter session_start() och $_SESSION med egen cookie-hantering och egna metoder för att registrera och läsa sessionsvariabler. Det var länge sen man behövde det. Däremot har många olika behov av lagringslösning för sessioner och det är en helt annan sak.

[kullervo]

Originally posted by dotvoid@Apr 5 2006, 00:25
Om du hanterar 200 sessioner per sekund tror jag inte det är snabbare med en databas än med en filbaserad lösning. Databasen måste också skriva och läsa data till och från disk. Dessutom måste den hantera index osv.

Jag misstänker att vi är helt överens egentligen. Är det så att det du kallar för "egen sessionshanterare" egentligen bara är dina userland-funktioner du registrerar via session_set_save_handler()? I så fall missförstod jag nog din första post.

Jag sa ju redan från början att det är helt onödigt att lägga sessions på disk. Självklart låter man inte sessions-tabellen i SQL-databasen heller ligga på disk. Och inte vill man att den ska logga ändringarna på disk heller. I MySQL finns ju HEAP-tabeller.

Nu har du inte tänkt till riktigt. Index är ju till för att snabba upp. Om du använder vettiga index går det snabbare. Om du missbrukar index så går det långsammare. Du kan ju inte utgå från att man använder korkade index bara för att man slänger upp sessions i en SQL-databas.

Nej, jag menar inte att en egen sessionhanterare använder PHP's färdiga sessionsfunktioner. Den sessionhanteraren jag gjort och som jag använder på ett flertal sajter är bara 12kiB stor. De timmarna det tagit att göra den och slipa på den är den värd många gånger om.

[dotvoid]

Som jag sa tidigare, vilka behov man har skiljer sig åt väldigt. Har man en distribuerad miljö med flera lastbalanserade servrar är det ganska meningslöst att hålla sessionsdata i minnet på en enskild server. Då har man andra behov än om man har en enda server. Då måste man ha en fristående server för sessioner - oavsett metod för datalager. Ofta används t ex LDAP-databaser som lagringsmetod för single-sign-on-system då det normalt ger väldigt snabb åtkomst till data.

Om du pratar om HEAP (eller MEMORY) i MySQL finns också en del nackdelar eller risker om du hanterar många sessioner. Låt säga att du behöver lagra sessioner i minnet för att orka med prestandamässigt - då har du troligen många sessioner du hanterar och hög trafik (eller en dåligt dimensionerad maskin). Om du skulle få osedvanligt hög last helt plötsligt riskerar du att slå i taket och då konverterar MySQL automatiskt minnestabellerna till diskbaserade tabeller. Orkar maskinen med det då om du inte dimensionerat för detta? Och om du dimensionerat för detta - varför inte köra med diskbaserade tabeller redan från början?

Vill du ha hög tillgänglighet och använder replikering mellan två eller fler databaser finns också problem med minnesbaserade tabeller som måste hanteras. Skulle master-databasen gå ner rensas de minnesbaserade tabellerna helt från data. Detta hanteras inte alls av child-servrarna som då behåller gammal data.

Oavsett vilken modell man väljer, distribuerad eller ej, ser jag fortfarande ingen vits med att inte använda $_SESSION och php:s inbyggda sessionsmekanismer eftersom man ju normalt sett bygger egna lagringsmetoder och registrerar dem. Jag har svårt att tro att du nånsin kan få bättre prestanda med 12k php-kod än om du använder dig av den kompilerade c-koden i php-interpretatorn - oavsett om du lagrar det lokalt i minnet eller använder dig av mer raffinerade modeller.

Däremot inte sagt att din kod inte fungerar. Det gör den säkert. Alla, eller många, skrev sin egna sessionshantering innan den inbyggda implementerades i php - även jag. Så du gör som du vill - bra va