Sabine: Lebensdauer der Sessions verlängern

Hallo,

ich benuzte in meinem PHP Script Sessions.
Nach dem Strat mit session_start(); setze ich einige Variable, z.B. $_SESSION['foo'] = ...

Nun sind nach einigen Minuten _manche_ dieser Variablen noch "richtig" belegt, manche jedoch haben ihren Wert verloren.

Das wirft zwei Fragen auf:

1. Warum verlieren manche Variablen ihre Werte früher als andere?

2. Wie kann ich die Lebensdauer beeinflussen (und evtl. in welchen Grenzen, zum Testen wären Werte von wenigen Sekunden recht praktisch). Das ganze möglichst nicht über die php.ini sondern im Script selbst oder in der .htaccess.

LG
Sabine

  1. Tach!

    1. Warum verlieren manche Variablen ihre Werte früher als andere?

    Sie "verlieren" ihre Werte nur, wenn die Sessiondateien vom Garbage Collector weggeräumt wurden. Der läuft sporadisch bei Script-Starts.

    1. Wie kann ich die Lebensdauer beeinflussen (und evtl. in welchen Grenzen, zum Testen wären Werte von wenigen Sekunden recht praktisch). Das ganze möglichst nicht über die php.ini sondern im Script selbst oder in der .htaccess.

    Welche Werte für den Garbage Collector gelten, steht im PHP-Handbuch im Kapitel zu den Konfigurationswerten von Sessions. Ebenso steht da, wo man sie verändern kann. Die meisten können noch im Script geändert werden.

    Das Problem wird vermutlich sein, dass du den Server nicht allein und zudem einen session.save_path verwendest, den auch noch andere Mithostlinge verwenden. Wenn die nun ihre Session-Lebenszeit-Parameter sehr niedrig eingestellt haben, dann räumt bei deren Scriptstarts der GC auch deine Session-Dateien früher weg. Abhilfe schafft in dem Fall nur, ein separates Verzeichnis (je Anwendung) zu verwenden.

    dedlfix.

    1. Tach auch!

      Welche Werte für den Garbage Collector gelten, steht im PHP-Handbuch im Kapitel zu den Konfigurationswerten von Sessions. Ebenso steht da, wo man sie verändern kann. Die meisten können noch im Script geändert werden.

      Meinst Du, ich muss session_cache_expire() verändern? Ehrlich gesagt verstehe ich das nicht so richtig. Was hat das mit dem cache zu  tun?

      Das Problem wird vermutlich sein, dass du den Server nicht allein und zudem einen session.save_path verwendest, den auch noch andere Mithostlinge verwenden.

      phpinfo() sagt:
      session.save_path no value

      LG

      Sabine

      1. Tach!

        Meinst Du, ich muss session_cache_expire() verändern? Ehrlich gesagt verstehe ich das nicht so richtig. Was hat das mit dem cache zu tun?

        Der Wert ist nur zusammen mit session.cache_limiter verwendbar - und für deine Belange sicherlich bedeutungslos. Es sind die session.gc_*-Werte, die für den Garbage Collector zuständig sind.

        Das Problem wird vermutlich sein, dass du den Server nicht allein und zudem einen session.save_path verwendest, den auch noch andere Mithostlinge verwenden.

        phpinfo() sagt:
        session.save_path no value

        Das heißt dann /tmp und die Chance, dass das andere auch verwenden, ist groß.

        dedlfix.

        1. Es sind die session.gc_*-Werte, die für den Garbage Collector zuständig sind.

          Also, session.gc_divisor ist auf "100", wenn ich jetzt auch session.gc_probability auf "100" setze wird der gc also bei jedem Scriptaufruf gestartet, richtig?
          Das bedeutet dann wohl, dass die Sessions bei jedem Scriptaufruf auf "Überalterung" (also älter als session.gc_maxlifetime) geprüft werden. Falls sie älter sind, werden sie gekillt, richtg?

          Das Problem wird vermutlich sein, dass du den Server nicht allein und zudem einen session.save_path verwendest, den auch noch andere Mithostlinge verwenden.

          phpinfo() sagt:
          session.save_path no value

          Das heißt dann /tmp und die Chance, dass das andere auch verwenden, ist groß.

          Ich schätze, dass ich eine längere Lebensdauer als meine Mithostlinge möchte. Kann ich dann einfach einen anderen Pfad setzen? Was ist dabei zu beachten?

          LG

          Sabine

          1. Tach!

            Also, session.gc_divisor ist auf "100", wenn ich jetzt auch session.gc_probability auf "100" setze wird der gc also bei jedem Scriptaufruf gestartet, richtig?
            Das bedeutet dann wohl, dass die Sessions bei jedem Scriptaufruf auf "Überalterung" (also älter als session.gc_maxlifetime) geprüft werden. Falls sie älter sind, werden sie gekillt, richtg?

            Richtig.

            Ich schätze, dass ich eine längere Lebensdauer als meine Mithostlinge möchte. Kann ich dann einfach einen anderen Pfad setzen? Was ist dabei zu beachten?

            Vor allem möchtest du eine unabhängige Lebensdauer. Zu beachten ist, dass der Pfad vom User des PHP-Prozesses beschrieben werden muss, aber möglichst nicht für andere zugreifbar ist. Und er sollte außerhalb des/der DocumentRoots liegen. Wie das zu bewerkstelligen ist, hängt von den individuellen Gegebenheiten des Servers und/oder der Konfigurationsmöglichkeiten ab.

            dedlfix.

            1. Also, session.gc_divisor ist auf "100", wenn ich jetzt auch session.gc_probability auf "100" setze wird der gc also bei jedem Scriptaufruf gestartet, richtig?
              Das bedeutet dann wohl, dass die Sessions bei jedem Scriptaufruf auf "Überalterung" (also älter als session.gc_maxlifetime) geprüft werden. Falls sie älter sind, werden sie gekillt, richtg?

              Richtig.

              Jetzt habe ich session.gc_probability auf "100" gesetzt, session.gc_divisor war schon auf "100".
              Resultat: Er merkt sich gar keine $_SESSION['xxx'] Variablen mehr. Wenn ich session.gc_probability auf Werte unter 100 setze geht es wieder...

              session.gc_maxlifetime steht auf "15".

              LG

              Sabine

              1. Tach!

                session.gc_maxlifetime steht auf "15".

                15 Sekunden sind ein bisschen knapp.

                dedlfix.

                1. session.gc_maxlifetime steht auf "15".
                  15 Sekunden sind ein bisschen knapp.

                  o.k., mit 60 sek. funktioniert es.

                  Vielen Dank!!!

    2. Hallo,

      1. Warum verlieren manche Variablen ihre Werte früher als andere?
        Sie "verlieren" ihre Werte nur, wenn die Sessiondateien vom Garbage Collector weggeräumt wurden. Der läuft sporadisch bei Script-Starts.

      ja, aber wie ist es dann möglich, dass bestimmte in der Session gespeicherte Werte "verlorengehen", während andere erhalten bleiben? Zumindest habe ich Sabines Frage dahingehend verstanden. Und nach meinem Verständnis putzt der GC doch die gesamte Session-Datei weg, wenn ihm danach ist, oder lässt sie ganz intakt. Aber er geht doch nicht die einzelnen gespeicherten Werte durch und löscht selektiv.

      Oder habe ich das Problem falsch verstanden? - Falls nicht, würde ich eher logische Fehler im Script selbst vermuten. Beispielsweise Daten, die fälschlicherweise überschrieben werden, oder Daten, die nicht sauber initialisiert sind.

      So long,
       Martin

      --
      Die letzten Worte des Neandertalers:
      Möchte doch zu gern wissen, was in der Höhle ist ...
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Tach!

        1. Warum verlieren manche Variablen ihre Werte früher als andere?
          Sie "verlieren" ihre Werte nur, wenn die Sessiondateien vom Garbage Collector weggeräumt wurden. Der läuft sporadisch bei Script-Starts.
          ja, aber wie ist es dann möglich, dass bestimmte in der Session gespeicherte Werte "verlorengehen", während andere erhalten bleiben?  Zumindest habe ich Sabines Frage dahingehend verstanden.

        Es könnte sich um eine ungenaue Beobachtung seitens des OP handeln.

        Und nach meinem Verständnis putzt der GC doch die gesamte Session-Datei weg, wenn ihm danach ist, oder lässt sie ganz intakt. Aber er geht doch nicht die einzelnen gespeicherten Werte durch und löscht selektiv.

        Ja, er löscht alles oder nichts.

        Oder habe ich das Problem falsch verstanden? - Falls nicht, würde ich eher logische Fehler im Script selbst vermuten. Beispielsweise Daten, die fälschlicherweise überschrieben werden, oder Daten, die nicht sauber initialisiert sind.

        Wäre auch eine Möglichkeit. Und wenn es wirklich nur einzelne Werte betrifft, dann wohl eher diese.

        dedlfix.