Login/Logout feststellen

[Shade Of Mine]

WirrWar2850 schrieb:

Verstehe, aber warum benutzen so viele Sites dann Sessions, wenn dieses (zwar kleine, aber vorhandene) Problem besteht???

Irgendeine Form von Sessions muss man zwangslaeufig verwenden, denn HTTP ist ja leider stateless.

Probleme haben die PHP Sessions ja eigentlich nur bei Clustern und bei sehr starkem Serverload. Deshalb kann man aber ohne Probleme eigene Session Handler installieren die dann zB die Datenbank oder einen Zentralen Fileserver oder sonst etwas verwenden um die Daten zu speichern. Das ist recht schnell geschrieben...

PHP Sessions haben aber den Vorteil, dass sie das Sessionhandling fast vollkommen vor dem Programmierer verstecken. Man muss nur session_start() aufrufen und das war es schon -> ist absolut genial (denn ein ordentliches Sessionmanagement zu implementieren ist nicht ganz so einfach).

Alles in allem sehe ich kaum einen Grund die PHP Sessions nicht zu verwenden (Handler, notfalls auch in C, sind schnell geschrieben um so etwaige 'Probleme' zu loesen).

Einzige Situationen wo eigenes Session Management sinnvoll sein kann:

1. Client based Session -> alles in Cookies packen
2. generell anderer Ansatz fuer das Session management, wenn man zB sehr starkes Caching oder sehr spezielle Situationen hat, wo man sehr spezielle Anforderungen hat.

[Gast]

WirrWar2850 schrieb:

Verstehe, aber warum benutzen so viele Sites dann Sessions, wenn dieses (zwar kleine, aber vorhandene) Problem besteht???

thx WirrWar2850.

schreibst du dir einen sessionhandler, der die inhalte der session in eine db schreibt, so kann auch der zweite server die informationen aus den sessions ausgelesen werden (und zwar aus der datenbank).
wenns also serverwechsel in der Applikation gibt, machst es halt mit einer Datanbank)
Für die meisten Zwecke reicht allerdings auch die Standardart.

[WirrWar2850]

OK, aber ich hab nur eine Site... und ich denke mal, da reichen normale Sessions vorerst mal aus.

thx WirrWar2850.

[Unix-Tom]

IMHO denke ich das die Filesession bei vielen Seitenaufrufen nicht ein Flaschenhals ist. Filezugriffe finden da sehr viele statt.

Da wäre:

Einlesen der Webseitenfiles mit den includes
LOG
Session

[WirrWar2850]

Ich werd mit der Zeit mal versuchen, was eigenes zu entwickeln, aber die erste Version der HP (geht am Donnerstag(meim Geb.) online) hat sowieso noch kein Benutzersystem, da gibts Gäste und sonst nix... (außer dem Admin )...

Trotzdem danke...

thx WirrWar2850.

[Shade Of Mine]

Unix-Tom schrieb:

IMHO denke ich das die Filesession bei vielen Seitenaufrufen nicht ein Flaschenhals ist. Filezugriffe finden da sehr viele statt.

Aber sie skalieren nicht.

Du kannst ohne Probleme die DB von dem Webserver auf einen eigenen Server setzen. Du kannst problemlos einen LoadBalancer vor eine handvoll Webserver schalten. Du kannst das aber nicht mit Session Dateien machen (es sei denn du hast einen Sessionbased LoadBalancer, der aber ansich ja nicht ideal ist). Du musst die Daten also irgendwo zentral speichern -> kostet viele Netzwerkzugriffe, weil du ja wirklich viele Session zugriffe hast.

Ich habe ja gesagt: normalerweise ist das kein Problem, aber man sollte trotzdem wissen wie Sessions in PHP implementiert sind, damit man eben nicht einen Cluster aufbaut und ploetzlich verlieren die Leute ihre Sessions.

Performance maessig sind die Festplattenzugriffe nicht so kritisch, aber in der Masse halt doch viel. Weil du eben nicht wie zB beim Logen nur 1 Datei hast, sondern pro User eine. Das kann schlecht fuer den Cache sein.

Ausserdem ist der Dateinbasierende GC recht lahm, weil er sich eben jede Datei ansehen muss ob sie noch legal oder schon veraltet ist. Hier kann man teilweise enorm optimieren indem man den GC seltener laufen laesst - und dann zB als Cronjob in der Nacht, statt von PHP waehrend der Stosszeit.

Aber ich wiederhole mich nochmal: normalerweise ist das alles kein Problem. Ueber anderes Session handling als die PHP Sessions muss man sich erst gedanken machen, wenn man feststellt, dass der aktuelle Server zu schwach ist (dann kann zB die Aenderung in eine Datenbank basiertes Speichermedium uU eine Linderung bringen, oder seltener den GC aufrufen, etc.) oder wenn man spezielle Anforderungen wie zB Client Only Sessions (wenn Speicherplatz auf dem Server nicht 'verschwendet' werden darf oder man aus sonstigen Gruenden die Daten nicht am Server speichern will). Sollte keiner der beiden Faelle eintreten sind die Standard PHP Sessions erste Wahl.

@WirrWar2850:
was eigenes ist zum ueben vielleicht lustig, aber ich bezweifle dass du wesentlich besser als die PHP Sessions werden kannst. Wobei ich da zwar ein paar gute caching ideen haette, lohnt sich die Arbeit wohl eher in einen Datenbankhandler als C Extension zu stecken (falls es sowas nicht schon geben sollte) - denn sowas lohnt sich wohl wesentlich mehr

Als Uebung oder zum Testen oder zum Spass ist es natuerlich voll in Ordnung ein eigenes Session handling zu schreiben.

Ich habe mal wo gearbeitet wo es ein eigenes Session handling gab -> da musste man ordentlich arbeit reinstecken weil es nicht skaliert hat. Im endeffekt war es nachher zwar schneller als vorher, aber mit PHP Sessions waere es besser gewesen.

Gerade in PHP sollte man sich oft ueberlegen ob es sich lohnt etwas selber zu implementieren, denn der C Code in einer Extension ist doch wesentlich schneller als PHP Code.

[Unix-Tom]

Ich habe mich auf

Nachteil bei den PHP Sessions ist, dass sie stark die Festplatte belasten, was uU ein Problem sein kann, deshalb kann man sich Handler schreiben die dann zB eine Datenbank oder andere Arten der Speicherung verwenden.

bezogen.

Weißt du eigentlich wer die Sessions löscht?
Für PHP läuft ja kein Daemon.

Problem mit dem Sessions und Logincheck. Die Session werden ja zu einer bestimmten Zeit gelöscht wenn der Client nichts mehr macht. Was aber wenn man eine Seite hat wo es sein kann das nichts gemacht wird. Man braucht da in jedem Fall eine Autorefresh der Seite.

Will man wissen ob jemand noch eingeloggt ist muss man schauen ob die Session noch da ist. Woher sollte man wissen welche Session ein bestimter User hatte.

Ich mache das bei meinen Seiten so.

Login: Eintrag in die DB (Flag von 0 auf 1)
Autorefresh jede Minute und setzen einen Timestamps in der DB

Daemon (man kann auch eine PHP/Perl was auch immer-Seite als Cron laufen lassen) checkt nun Regelm. ob Timestamp um 2 Minuten < als JETZTZEIT. Wenn ja in DB Flag auf 0 und ausloggen.

Das hat bei mir noch keine Probleme gemacht.
Viele andere Möglichkeiten gibt es eh nicht.

[Shade Of Mine]

Unix-Tom schrieb:

Weißt du eigentlich wer die Sessions löscht?
Für PHP läuft ja kein Daemon.

PHP hat hier einen probability GC.
Bei jedem Aufruf einer PHP Seite (ich weiß jetzt nicht ob es eine Rolle spielt ob session_start() aufgerufen wird oder nicht) wird mit einer gewissen wahrscheinlichkeit der GC gestartet und löscht die alten Sessions.

Der genaue Mechanismus ist mir nicht bekannt, ich vermute aber, dass PHP nach dem Ende des Scripts den GC startet. Ob das in einem low priority Thread oder sonstwie geschieht, weiss ich leider nicht.

Man braucht da in jedem Fall eine Autorefresh der Seite.

Hatten wir uns auch einmal überlegt, hätte aber zu viel sinnlosen Load erzeugt.

Und will man wirklich die Session möglichst exakt beenden? OK, wollen schon, aber nötig ist es eigentlich nicht. Das einzige Problem dass man hat ist Session Hijacking, aber dagegen kann man sich eigentlich ganz gut sichern...

Login: Eintrag in die DB (Flag von 0 auf 1)
Autorefresh jede Minute und setzen einen Timestamps in der DB

Erzeugt das nicht sehr viel Load?
Bei 100 Usern natürlich kein Problem, aber wenn du 5000 User angemeldet hast? dann sind das alle 0,012 sekunden eine DB abfrage...

vielleicht denke ich aber auch in zu großem maßstab.

Das hat bei mir noch keine Probleme gemacht.

Kommt auf die Anzahl der User an. Bei 100 eingeloggten ist es sicher kein Problem.

Aber warum will man eine Session minutengenau beenden? Reicht es nicht das Refresh auf "SessionTimeout - eine Minute" zu stellen? Es sei denn wir reden hier gerade von einem Chat oder ähnliches, dann braucht man es natürlich genau und hat das Refresh ja zwangsläufig weil man den geschriebenen Text ja aktualisieren muss (streaming html mal ausgenommen). Aber bei einer normalen Webseite würde ich soetwas nie implementieren.

[Unix-Tom]

Ich spreche hier von einem Chat.
Der hat keine 5000 User.
Wer will schon bei sovielen Usern einen genauen Logout. Ist Applikationsabhängig.
Da müsste man dann anders Planen.

[Shade Of Mine]

Unix-Tom schrieb:

Ich spreche hier von einem Chat.

Dachte ich mir fast

Da sind die Anforderungen natürlich ganz anders als an eine Webseite. Und ich gehe eigentlich von 'normalen' Webseiten aus, denn Chats, Foren oder ähnliche Sachen haben grundlegend verschiedene Anforderungen...