Citat:
|
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.
Citat:
|
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.