!! Community Portal BUG !! Sessionhandling? Php Einstellungen? Apacheconfig? Server?

A5 Infoschlampe

Erfahrenes Mitglied
Hallo Tutorials Gemeinde ;-),

ich hätte mal folgende Frage zu einem Bugfixing, wo wir zur Zeit nach mehrwöchiger Suche leider völlig Ahnungslos sind :(

Vorwort:
Wir betreiben eine Community Seite, realativ neu da Start November 06, in denen sich die User einloggen und sich gegenseitig kennen lernen. Dabei ist ein User in unserm System intern ein Objekt mit vielen Eigenschaften, Methoden etc. Da die Daten jeweils pro Klick aktuell sein müssen(!) (letzte Aktivität, Punktestände etc.), gibt es eine zentrale Funktion, die jeweils die Objektdaten aktuell refresht, konstant überprüft und alle Eigenschaften des Users in die SESSION schreibt, damit wir modulweit auf diese Werte zugreifen können. Unter anderem ist dort auch ein Flag
PHP:
$_SESSION [ ' benutzer' ]  ['benutzer_ist_eingeloggt' ] = [TRUE/FALSE]
über dass wir in den einzelnen Moduln dann überprüfen können, ob die jeweilige Ausführberechtigung gegeben ist. Natürlich auch zentral verzweigt.
Nun ist die Community in den letzten 2 Monaten ganz gut gewachsen, sowohl in den Userzahlen (Registrierungen nud gleichzeitig Online), als auch im Traffic.

Systeminfo:
Das CMS ist bewusst komplett selbstgeschrieben, da wir von "Fertig-Lösungen" nicht viel halten aus diversen Gründen (Sicherheitslöcher, Unbekannter Code, etc.)
Läuft mit Php4 und MySql.

Die Hardeware ist ein eigener Root mit
  • Debian
  • Apache2
  • Php4.3.10
  • MySql Ver. 14.7 Distri. 4.1
  • Sun JDK 1.5
  • Tomcat 5.5.

Problem:
Eigentlich lief das ganze bisher durch zuverlässig und stabil, ABER seit neuestem tritt der Fehler auf, das ein User nach einem Klick, PLÖTZLICH ausgeloggt ist, obwohl dieser noch eingeloggt sein müßte (ein Klick ruft ja wieder die zentrale ÜBerprüfung auf etc... die bis dato 2 monate zuverlässig lief!). Aufgrund der algorithmischen korrektheit des Codes sind wir da im Moment überfragt, warum der User rausfliegt und sich neu einloggen muss.
Dies tritt sehr unregelmäßig auf und kann von uns bisdato nicht rekonstruiert werden. Es passiert zu den unterschiedlichsten Uhrzeiten mit unterschiedlich vielen Usern online.

Daher die Vermutung, ob es vielleicht auch auch mit dem Server und der Sessionverwaltung zu tun haben könnte ? :confused:

Meine Frage an Euch wäre nun, ob Ihr ähnliche Erfahrungen im Sessionhandling gemacht habt, oder ob ihr Ideen haben könntet, wo wir die Suche weiter fortsetzen können.
Ich dachte z.B., dass aufgrund des Anstiegs der Userzahlen vielleicht von Apache automatisch Sessions gekillt werden etc..

Habt ihr da Erfahrung, ob es Servereinstellungen gibt, die bei wachsenden Community unbedingt beachtet werden müssen? :confused:


Für jeden Post bedanke ich mich schonmal im Vorraus!!
Viele Grüße,

Dan
 
Habt ihr bei so einem Projekt keine ordentliche Fehlerbehandlung? Denn ich denke doch, dass dies aufgrund eines Fehlers im System passiert.
 
Das Projekt ist aussergewöhnlich proffessionell aufgezogen, damit meine ich die ganze Systemlandschaft, Codebetreuung etc. Dies schließt ebenfalls das Errorhandling ein.

Ist aber auch nicht das Thema der Frage gewesen.

Der Algorithmus ist ok, aber das ganze hier zu posten um das sehen zu können würde ja jetzt keinen Sinn machen, ... da müsstest du mir schon vertrauen :)

Meine Suche geht nun in "äußere Umstände" die dazu führen könnten...:confused:
 
Genau das selbe Problem hab ich bei einer Seite von mir auch, allerdings ist das nur eine kleine Vereinsseite, wo man sich einloggen kann und die Inhalte verwalten kann.

Die Problematik: Nach dem Einloggen mach ich einen Klick und bin sofort wieder ausgeloggt. Nach dem zweiten Einloggversuch bleib ich eingeloggt und kann auch ganz normal arbeiten.
Ausserdem tritt das Problem nur im Firefox auf (wenn ich mich recht entsinne).

Hab die Seite mal testweise auf einen anderen Server gelegt, da funktionierte es. Keine Ahnung ob da der Server schuld ist oder ob irgendwo ein Fehler im Script ist...
 
Tritt das Problem vielleicht auf wenn eine laengere Seite gelesen wird, sodass es vielleicht zu einem Session-Timeout kommt?
Moeglicherweise wurde die Ablaufzeit fuer Sessions heruntergesetzt und dass Problem kommt dadurch zustande.
 
@Dennis
Danke - guter Ansatz.

Also das Session Timeout ist auf 25 Minuten gesetzt - du hast recht, dass der Fehler meistens passiert (laut Userberichten), wenn diese klicken, den PC kurz verlassen, und nach einigen Minuten wiederkommen (2,5,10..) beim Folgeklick ausgeloggt sind.

Allerdings ist der Timeout wert zu hoch für die Beschriebene Zeit.

Ist es rein theoretisch möglich, dass auf dem Server der "Sessionspeicher" z.B. aufgrund der Daten und der Useranzahl "voll" ist, somit somit vorherige Session killt, obwohl diese noch nicht abgelaufen ist :confused: :confused:
 
@Dennis
Danke - guter Ansatz.
Nichts zu danken, dafuer sind wir ja hier. ;)

Also das Session Timeout ist auf 25 Minuten gesetzt - du hast recht, dass der Fehler meistens passiert (laut Userberichten), wenn diese klicken, den PC kurz verlassen, und nach einigen Minuten wiederkommen (2,5,10..) beim Folgeklick ausgeloggt sind.
Eine eigene Garbagecollection mit einem eigenen Timeout, also unabhaengig vom PHP-Timeout fuer Sessions habt ihr nicht, oder? Sowas setze ich naemlich auf meiner Website ein.

Ist es rein theoretisch möglich, dass auf dem Server der "Sessionspeicher" z.B. aufgrund der Daten und der Useranzahl "voll" ist, somit somit vorherige Session killt, obwohl diese noch nicht abgelaufen ist :confused: :confused:
Ich denke, dass in dem Fall wohl eher neue Sessions nicht angelegt wuerden als dass alte Sessions gekillt werden. Entsprechend wuerde ich das jetzt erstmal ausschliessen, auch wenn es natuerlich durchaus moeglich waere.

Und falls Ihr nicht grossartig die php.ini vergewaltigt habt und auch nicht die Sessions selbst gross verbogen habt werden diese auf der Festplatte abgelegt, in der Regel in /tmp.
Und die Session-Files sind auch meist ziemlich klein. Der Dateiname enthaelt die SessionID und die Datei selbst enthaelt im Klartext (falls Ihr nicht mit Suhosin arbeitet) die in der Session gespeicherten Daten, mehr nicht. Entsprechend klein ist die Datei dann halt auch.
Nun ist die Frage zu welcher Partition /tmp bei Euch gehoert, oder ob es vielleicht eine RAM-Disk ist, und wieviel Platz dort eben zur Verfuegung steht.

Um den Speicherort der Session festzustellen, um sicher zu gehen, koennt Ihr uebrigens mit session_save_path() arbeiten.
 
Eine eigene Garbagecollection mit einem eigenen Timeout, also unabhaengig vom PHP-Timeout fuer Sessions habt ihr nicht, oder? Sowas setze ich naemlich auf meiner Website ein.

... Korrekt vermutet - wir haben eine eigene GarbageCollection, welche nach 45 Minuten aktiv wird. spät. 45 nach Inaktivität wird der User automatisch ausgeloggt und sein komplettes Array ins Nirvana geschickt :)
Lieder macht das System das im Moment ja zufällig schon bei manchen Usern nach einigen Minuten..:mad:

Ich denke, dass in dem Fall wohl eher neue Sessions nicht angelegt wuerden als dass alte Sessions gekillt werden. Entsprechend wuerde ich das jetzt erstmal ausschliessen, auch wenn es natuerlich durchaus moeglich waere.

... wenn weitere User sich da genau auskennen, wäre ein Post für dieses Thema cool ! :)

Und falls Ihr nicht grossartig die php.ini vergewaltigt habt und auch nicht die Sessions selbst gross verbogen habt

:D Sorry nein

Und die Session-Files sind auch meist ziemlich klein. Der Dateiname enthaelt die SessionID und die Datei selbst enthaelt im Klartext (falls Ihr nicht mit Suhosin arbeitet) die in der Session gespeicherten Daten, mehr nicht. Entsprechend klein ist die Datei dann halt auch.
Nun ist die Frage zu welcher Partition /tmp bei Euch gehoert, oder ob es vielleicht eine RAM-Disk ist, und wieviel Platz dort eben zur Verfuegung steht.

... wir haben über 600GB auf Raid 1 laufen - also platzmäßig ist alles OK.
Allerdings habe ich mir diese Files noch nicht angeschaut - anhand des Inhalts könnte ich für einen User, der direkt "geflogen" ist, vielleicht weitere Analysen machen. Reni theoretisch müsste sich ja der Inhalt komplett "Leeren", wenn seine Session geNull't wird, oder?! ... Zumindest sollte sich das File ändern :confused: ...

Ok das ist ja schonmal ein neuer Probieransatz, an den wir noch nicht dachten....

Weitere Ideen und Vorschläge gerne Willkommen :confused:
Thanx!
 
Und Client seitige Fehler schlisst ihr völlig aus? Es könnte ja auch sein das es ein Problem des Clients ist. Oder ist es bei alles Clients der Fall? ...
Muss grad weg, wollt nur diesen Gedanken mal noch in den Raum werfen ^^

cu

MFG Adi
 
Zurück