[totoo]

den där metoden känns dock skapligt dryg då jag faktiskt utnyttjar sessionernas stora fördel, att det är smidigt och sparsamt att lagra mycket innehåll där i. Jag cachar skitmycket data där i och min sessionsarray innehåller med lätthet 200 rader med blandade värden, mest tal.

Jag optimerar alltså tokmycket genom att komma ihåg saker i sessioner istället för att gräva fram informationen om och om igen vid varje sidladdning. Fast jag kan ju förvisso kanske spara en del saker på andra ställen.

Men det kanske är dags att fördjupa sig riktigt och se om denna sessionsmetod håller i längden. Jag försöker verkligen undvika att behöva göra om saker typ två år efter vi öppnat. Så även om vilka skitlösningar som helst håller i början och siten kanske går dåligt så att vi aldrig ens får behov av bra lösningar, men jag sätter ribban så högt jag kan.
Men ibland är man ju ovetande och inte känner till allt, just det här med smarta lösningar kring lastbalansering är jag helt lost på.

Men det här med att sessioner lagras fysiskt, det borde väl gå att göra så att de delas mellan flera datorer? eller att de raidas eller nåt. Jag menar, databasservern kommer ju också vara på en annan burk, så att hämta info ifrån en databas från en annan burk, eller hämta sessionsinformation borde ju vara ungefär same shit. Så utan att ha inblick i hur det verkligen fungerar så tycker jag att det borde vara soft även med sessioner.

Annars är du välkommen att rätta mig.

Tack!

[Robert]

Ett litet inflik ang AJAX: ajax är, enligt mig, till för att förhöjja användarupplevelsen för användaren. Detta tar några miste på och slänger in ajax där det eg inte behövs; resultatet blir inte bättre för någon. Att höjja den *upplevda* prestandan för en användare betyder absolut inte att det blir bättre "fysisk" prestanda (eller hur vi ska benämna det). Det är helt beroende från fall till fall och hur just din målgrupp hanterar den aktuella sidan.
I ett fall med Ajax kanske du behöver göra i snitt 5 databasslagningar istället för 1, men slipper undan med lite Kb när du skickar httpsvaret. Om detta optimerar din trafik/belastning kan bara du avgöra.

[danjel]

Men det här med att sessioner lagras fysiskt, det borde väl gå att göra så att de delas mellan flera datorer? eller att de raidas eller nåt. Jag menar, databasservern kommer ju också vara på en annan burk, så att hämta info ifrån en databas från en annan burk, eller hämta sessionsinformation borde ju vara ungefär same shit. Så utan att ha inblick i hur det verkligen fungerar så tycker jag att det borde vara soft även med sessioner.

Hmm jo det går väl men det känns enklare att dela sessioner mellan olika burkar om sessionerna ligger på en db, känns rätt bökigt/långsamt att hämta sessionsdata från en annan burk om man inte gör ett db anrop..

Ett alternativ är att köra sticky sessions, om man ska ha sessioner lagrade på varje server i ett kluster,men då måste klienten hela tiden köra mot samma server
och lastbalanseraren ha koll på vilken server en viss request ska gå mot..

Men om du ska ha maximal pestanda, default blir det en läsning /skrivning mot filsystemet med vanliga default sessions inställningen, vilket inte är helt optimalt
Tror det går snabbare att lagra sessionerna i en MYSQL MEMORY (HEAP) tabell så man slipper just disk I/O utan kör mot minnet, även om jag inte har gjort prestanda mätningar..

(Det går ju att använda default sessions och köra mot db om man ändrar i session_set_save_handler())

"Shared memory managed sessions" finns det nåt som heter om man ska spara sessioner i minnet men de är inte helt tillförlitliga (enligt php.net)

[grazzy]

Bästa om du har kapabiliteten är nog att skriva en egen session-deamon du kör på en egen burk (kanske tillsammans med ditt ticket system eller liknande mindre krävande processer) som du själv kan speca protokoll och lagrings-system för. Tex bara en hash :P

Att köra en strippad mysql på dedikerad burk med heaps borde ju vara nästan lika bra om man inte orkar koda själv ... SHM-grejerna blir snabbt bökiga när du skall dela mellan flera maskiner ...

Mitt bästa tips för nuvarande: du kommer långt, riktigt långt med EN kraftfull webbserver som jobbar mot flera databaser. Alltså är inte detta ett problem du måste lösa nu, utan du kan tryggt avvakta tills problemet uppstår och då lösa det genom att som ovanstående postare säger implementera en wrapper-klass som sköter dina session-requests nu.

[totoo]

Robert
Ja, det är säkert sant, men om man har designat sin applikation så dumt så får man skylla sig själv. Jag menar bara att ajax är en bra optimering om man använder det till att INTE ladda in information som inte behövs. Att bara ladda om en del av sidan istället för hela sidan är en optimering, utan undantag (förutsatt att man inte har gjort något väldigt konstigt med sin applikation, men låt oss förutsätta att programmeraren kan koda).

Ett bra exempel är t.ex. på fz.se som jag hittade igår, en bit ned på första sidan "FZ Releases" där de har små ajaxdrivna flikar för att byta innehåll. Sånt där lönar sig för alla jämfört med att sidan t.ex. skulle ha laddats om (vilket naturligtvis inte ens skulle ha kommit som förslag med just det där innehållet, men det där är en styrka hos ajax).

Att jag gör stora optimeringar med ajax är det ingen tvivel om.

Danjel
Tack för tankarna... Jag måste fundera lite på det där, jag har skjutit upp problemet, jag måste sluta med det snart. Efter jul ska jag försöka ha kommit fram till något bra. Just nu har jag en spelhall att styra upp som ska betatestas om ett par dagar.

grazzy
Hmm, så kanske borde man köra en dedikerad mysqlserver som sköter sessionerna alltså. Det låter vettigt, nackdelen är ju fortfarande den delen med att jag sparar så tooookmycket information i sessionerna idag att jag inte riktigt ser det som en bra lösning att använda cookies (jag vet inte ens om allt får plats i dem). Jag vet inte vad det får för effekter, men om medlemmarnas cookies växer från att ha tre variabler till femhundra så blir det ju bra mycket mer in-trafik för siten, uttrafiken ökar ju också för den delen, även om det kanske spelar mindre roll.

Men jag kanske får tänka om, jag har hittat mina metoder som har vart bra för tillfället och som har gett mig bra lösningar, men de kan ju vara sämst i världen på sikt.

Så kluven jag blir.

Men vad finns det för bra metod för att lagra sessioner ( inkluderande datan) på servern?

För ni tänker väl er inte att sessionsvariablerna ligger i databasen antar jag?

[danjel]

Men vad finns det för bra metod för att lagra sessioner ( inkluderande datan) på servern?

För ni tänker väl er inte att sessionsvariablerna ligger i databasen antar jag?

Jo, alltså exempel på kolumner i tabellen:

sessions_id,
sessionsdata

Då blir datat typ:

rad1:

kshdfhhs7f7s78s7f , // motsvarar cookie värdet i sessionscookien
99 // tex user_id

rad2:

kshdfhhs7f7s78s7f , // samma sessions id
123 // annat värde

[totoo]

ehm, du behöver väl ett index för varje också så att man vet vilken rad som är vad?

Men det gör lite ont i hjärtat att använda en sån lösning nu när jag har proppat sessionerna fulla med saker som gör att jag behöver hämta mindre information från databasen. Jag har ju t.ex. ibland klämt in saker i sessionen bara för att kunna ta bort en query ibland. Okej att detta kanske inte blir sååå illa, eftersom sessionen även med den vanliga metoden måste kommas åt, och att det blir overhead där, men detta lär kosta betydligt mer antar jag.

Men som sagt, jag kanske få göra om hela mitt sessionsanvändande från grunden.

[jimmie]

Hej,

Jag ger tipset(kanske tidigare nämnt i tråden) att skapa en session-klass som du använder dig av, då får du ett abstraktionslager mellan dina script och session-hanteringen och kan på ett enkelt sätt optimera sessionhanteringen längre fram om du tycker att prestandan är för dålig.

God Jul!