[php5] sessions / Problemen met session_regenerate_id(true)

[DPLuS]

Even een klein vraagje,
als ik een session_regenerate_id(true) doe, moet ik toch maar 1 sessie terugzien in mijn session-path?
Volgens de manual wel: http://nl.php.net/manual/en/function.session_regenerate_id

Maar nu heb ik het volgende script:

PHP:

<?php
session_start();

$old_sessionid = session_id();

session_regenerate_id(true);

$new_sessionid = session_id();

echo "Old Session: $old_sessionid<br />";
echo "New Session: $new_sessionid<br />";

echo "Please look for the amount of newly created sessions in " .
session_save_path();

?>

Ik heb zelf Debian Etch Linux, dus sessies worden standaard opgeslagen in /var/lib/php5.

Ervan uitgaande dat deze directory helemaal LEEG is (rm -rfv *), gaan we dit script uitvoeren.
Wat we zullen zien is dat er maar 1 sessie in staat:

code:

testing:/var/lib/php5# ls -al
drwx-wx-wt  2 root     root     4096 2007-10-09 11:38 .
drwxr-xr-x 40 root     root     4096 2007-06-05 17:46 ..
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_bf25d463bd2427077362a6a5c3322a8c

Maar nu houden we in Internet Explorer (of Firefox) de F5 knop een paar seconden in (stresstest )
en warempel: nu zien we dat er ineens een hoop sessies aangemaakt zijn die er eigenlijk niet horen te zijn, want de parameter voor session_regenerate_id staat op TRUE, dus vervang oude sessies:

code:

testing:/var/lib/php5# ls -al
drwx-wx-wt  2 root     root     4096 2007-10-09 11:38 .
drwxr-xr-x 40 root     root     4096 2007-06-05 17:46 ..
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_05d70781a104576f23543b3299b7d05e
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_0d6768211b29ad84164fd6d070c3762e
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_12dd6823740e2c84b330291e1f60c827
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_1421b917ab0666ccc0c9d18af389b4ca
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_20df609512f16755cf4dd1eafffe3814
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_252628d760472fe02722826198751414
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_28133ab73aceaeccb23469bc73da1981
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_2d37a949a7dd1afba9bd1e4f5c1f0531
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_43228c7f103201826c7b2d6bbc78d248
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_4a66e1f7c0d07ba18a7fa9dd55f2d49c
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_52c5d429af6f70f67d09b17a1040787d
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_58ed4a00f2109cf5eb56e43d93efb53e
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_5e786f82712a14d8f28848c91a8ebbf5
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_6171d6c50102d4bb5431f2df3ef350fe
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_6d44894c28bf9205181d34069fb2d04b
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_769fd1220a7172970ea5c7ea0d430d4a
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_8ea18f64b65855c1f32001fab4914c8e
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_8ff371c1c45baa9a8aea16cb06139809
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_921cc5fa79e853887fd3e9ea198a1f80
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_939158cbe08761c5bf69b1a8be9103bb
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_95a8e110ed80e63025a824f837268b17
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_97c6da00dee72e2ccca73f3a29e8bb9d
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_980c5f99114e6e6cac7fb1cebed3ede1
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_ab81e84b43f7cd0e0c22e550855908a4
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_ad66254ba12421449dd1572b6f7a9393
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_b4f679b4d811464a25598bcb6ee6d795
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_b837bc487e12b7c2883b57777c79a623
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_d6d766f8fd49ac666b91ea7265b8a1eb
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_dc7acb0dc58d7954d0a077b5c1878ee8
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_e9611bdca067a9d88a3a54ce87f6acf1
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_f862d38b27516300e19f39a5156b8789
-rw-------  1 www-data www-data    0 2007-10-09 11:38 sess_fd61f58bbf408d149626727f5ed2ab3d

Mijn vraag is nu: hoe kan dit?
Het lijkt wel alsof de PHP engine door de snelle requests geen tijd heeft om de sessies te vervangen ofzo?

Ik heb een bug ingediend bij php.net (http://bugs.php.net/bug.php?id=42899) maar er werd mij verteld dat het te maken had met de garbage collector.
Ik ben het daar niet mee eens, want als ik gewoon de HTTP-request 1 keer per seconde doe gaat het wel gewoon goed (Dus dan zie ik gewoon één sessie in de map staan).

Wat doet het script bij jullie? En is dit een bug of een feature??

[FragFrog]

Dit is gewoon precies zoals het hoort hoor.

PHP heeft een garbage collector die alle oude sessies opruimt als ze verlopen zijn. De kans dat deze garbage collector aangeroepen wordt is standaard 1%, dit kun je ook aanpassen (met bijvoorbeeld ini_set). Als je dit op 100% zet zul je zien dat je altijd maar 1 sessie in je dir hebt staan per gebruiker (wat overigens niet aan te raden is, oude sessies kunnen doorgaans geen kwaad en het is toch weer een performance drain).

Lees je eens in hoe sessies werken voordat je bugreports in gaat dienen voortaan

Helaas is de documentatie bij session_set_save_handler() erg summier anders zou ik je willen aanraden eens je eigen session handler te schrijven, erg leerzaam

Last but not least, de session garbage collector wordt voor session_start() aangeroepen (als hij aangeroepen wordt, zie die gc_probability weer) dus het is zeker niet zo dat je server de snelle requests niet aankan - dan zou je namelijk juist minder sessie's zien, niet meer

[ Voor 59% gewijzigd door FragFrog op 10-10-2007 22:04 ]

[DPLuS]

Nee, waar het om gaat is dat de parameter TRUE in de functie:

code:

session_regenerate_id ( [bool $delete_old_session] )

ervoor dient te zorgen dat de oude sessie dus meteen verwijderd wordt.

En dat gebeurt nu dus niet.

Dat doet 'ie wel als ik een aantal requests per seconde doe, maar indien ik continue op F5 druk (page refresh) blijven de oude sessies dus gewoon bestaan.

Ik snap niet waarom dit is, en aangezien het niet expected behaviour is wil ik het aanmerken als een bug.

[ Voor 12% gewijzigd door DPLuS op 06-11-2007 13:18 ]

[Verwijderd]

Whether to delete the old associated session file or not. Defaults to FALSE.

Dit staat in de manual, er staat dat het bestand verwijderd wordt en niet specifiek of het direct gebeurd of op een later tijdstip. Ik vraag me ook af of het zinvol is om hier verder over te discussieren, het maakt toch geen bal uit, als het bestand uiteindelijk maar verwijderd wordt...

[Voutloos]

Precies, dat 'meteen' staat nergens. Het gaat blijkbaar via een garbage collector en daarmee is de vraag beantwoord. Je kan dan nog hoogstens willen dat het via de GC opruimen duidelijker gedocumenteerd moet worden.

[FragFrog]

5.1.0 Added the delete_old_session parameter.

Welke versie van PHP5 gebruik je precies?

[Voutloos]

In zijn bugreport staat 5.2.4

[FragFrog]

Voutloos schreef op dinsdag 06 november 2007 @ 17:50:
In zijn bugreport staat 5.2.4

Pff, over informatie verstoppen gesproken Lijkt er dan inderdaad op dat die param enkel de mogelijkheid openlaat dat de sessie destroyed wordt, merkwaardig.

Overigens is dit bij uitstek een reden om lekker je eigen sessie-handler te gebruiken, dan weet je tenminste wel precies wat er gebeurt

[Verwijderd]

wat je doet met continu op f5 drukken is steeds requests versturen maar je wacht niet tot hij klaar is. hij heeft dus helemaal nog geen tijd van je gekregen om de troep op te ruimen.

betere stresstest is door iets te bakken dat steeds de verb opent, file binnenhaalt, wacht tot hij klaar is. en dat in een loop.

[Voutloos]

FragFrog schreef op dinsdag 06 november 2007 @ 18:57:
Overigens is dit bij uitstek een reden om lekker je eigen sessie-handler te gebruiken, dan weet je tenminste wel precies wat er gebeurt

Als zoiets al 'bij uitstek een reden' om iets zelf te doen ben je de komende 100 jaar nog bezig met het wiel opnieuw uitvinden.
Of je ligt gewoon niet wakker als een sessie toevallig een paar seconden langer blijft bestaan of als je echt wil verhoog je de kansen dat de GC langs komt.

[FragFrog]

Voutloos schreef op dinsdag 06 november 2007 @ 19:27:
Als zoiets al 'bij uitstek een reden' om iets zelf te doen ben je de komende 100 jaar nog bezig met het wiel opnieuw uitvinden.

PHP's sessie handler maakt gebruik van files, dit heeft, zeker in geclusterde omgevingen, grote nadelen tov het gebruik maken van een database. Een sessiehandler schrijven die daar gebruik van maakt heb je in onder 50 regels code klaar, dat gaat een stuk sneller dan een topic ervoor openen hier op GoT en geeft je bovendien meer informatie, meer flexibiliteit en meer controle.

Er zijn legio dingen die je beter zelf kan schrijven en vervolgens hergebruiken, daar heb je echt geen 100 jaar voor nodig. Blijven doorprutsen met iets wat net niet doet wat je wil, daar ben je pas veel tijd (en frustratie) aan kwijt.

Verwijderd schreef op dinsdag 06 november 2007 @ 19:24:
wat je doet met continu op f5 drukken is steeds requests versturen maar je wacht niet tot hij klaar is. hij heeft dus helemaal nog geen tijd van je gekregen om de troep op te ruimen.

Voor elke request zal PHP altijd zichzelf constructen en daarmee bepaalde zaken uitvoeren en achteraf altijd zichzelf destructen en daarmee bepaalde zaken uitvoeren, ongeacht of het script halverwege afgebroken wordt. De session garbage collector wordt standaard altijd vantevoren uitgevoerd, het wegschrijven van de sessie standaard altijd achteraf. PHP neemt dus altijd de tijd om die troep op te ruimen.

[ Voor 33% gewijzigd door FragFrog op 06-11-2007 20:29 ]

[Voutloos]

Anders geef je nu opeens een andere, veel betere, reden om een eigen session handler te schrijven...

[FragFrog]

Voutloos schreef op dinsdag 06 november 2007 @ 20:32:
Anders geef je nu opeens een andere, veel betere, reden om een eigen session handler te schrijven...

Owja? Welke dan? De TS heeft het probleem dat PHP's standaard session handler niet doet wat hij wil, ik noem dat een aanleiding om je eigen te schrijven. Dat je dan bijvoorbeeld ook de mogelijkheid krijgt om sessies op te slaan in een database is vanzelfsprekend en geimpliceerd in het 'goede aanleiding tot', anders had ik er wel neergezet 'enige reden om'.

Je gaf zelf al aan dat je niet altijd het wiel opnieuw uit moet vinden, ik voeg daar aan toe dat je het enkel moet doen als je er een aanleiding voor hebt en de moeite van het zelfschrijven minder is dan proberen de standaard tool te laten doen wat je wilt. Een session handler heb je echt zo geschreven, dat is absoluut geen moeite (ik durf te wedden dat ik het in minder dan 20 regels code nog wel kan), dus daar hoef je helemaal geen enorm grote aanleiding voor te hebben. Of je nu je persistant sessies achter een loadbalancer wilt hebben, ze automatisch wilt destroyen of simpelweg een mailtje wilt sturen zodra iemand inlogt om maar een zijweg in te slaan is irrelevant - wat relevant is is dat ze een aanleiding zijn om er zelf eens naar te kijken, dat beweerde ik en daar blijf ik bij.

[ Voor 11% gewijzigd door FragFrog op 06-11-2007 22:49 ]