nicht angemeldet
Wie groß darf die Session-Variable sein?
Hallo liebe Forumsteilnehmer!
Ich hab kein Gefühl wieviel man in den PHP-Session-Array reinpacken darf. Wenn ein Datensatz beispielsweise so aussieht:
Vorname
Nachname
Land, Ort
5 Zeilen a 80 Zeichen Beschreibung zu Person
Ist es kein Problem 50 solche Datensätze in die Session-Variable reinzutun, oder doch eher Schwachsinn?
Besten Dank
Viennamade
-
Hello InWienGemacht,
fragt sich als erstes, ob das unbedingt in der Sessiondatei drinstehen muss, oder ob diese Datensätze nicht lieber in ihrer Datenbank residieren sollten.
Geh mal davon aus, dass man die Sessiondatei als "Arbeitsspeicher" ansehen sollte. Bei PHP < 5.0 kann man leider nicht verhindern, dass sowohl $_SESSION, als auch $HTTP_SESSION_VARS angelegt wird. Das bedeutet also eine schlimme und nutzlose Speicherverschwendung. Wenn Deine Sessiondatei nun also 2MB groß wird, was für eine Datei in modernen Systemen überhaupt kein Problem sien sollte, dan frisst sie Dir aber 4MB vom Scriptspeicher. Und der ist i.d.R. begrenzt auf 8 oder 10MB, wenn --enable-memory-limit mit eincompiliert wurde.
Solange Du also nicht an die Speichergrenze für Dein Script stößt, hätte ich da keine Bedenken, 2MB in der Session zu parken. Immerhin handelt es sich nur um einen einzigen Lesezugriff und einen Schreibzugriff pro Scriptaufruf. Bei Datenbankabfragen entsteht schon wesentlich mehr Overhead.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Solange Du also nicht an die Speichergrenze für Dein Script stößt, hätte ich da keine Bedenken, 2MB in der Session zu parken. Immerhin handelt es sich nur um einen einzigen Lesezugriff und einen Schreibzugriff pro Scriptaufruf. Bei Datenbankabfragen entsteht schon wesentlich mehr Overhead.
Andererseits dauert ein Schreibzugriff für 2 Megabyte an Daten (wobei anzumerken ist, dass durch das serialisieren des Arrays bei ungünstigen Daten ein Vielfaches an Datenmenge entstehen kann) doch schon eine gewisse Zeit. Und damit sich Schreib- und Lesezugriffe nicht gegenseitig stören, wird die Datei exklusiv gelockt für das gerade beendete Skript, um die Session-Variablen zu speichern - in der Zeit kann kein anderes Skript starten und die Datei einlesen.
Es ist also das grundsätzliche Problem, dass Sessions sich gegenseitig stören, wenn man den Standard-Mechanismus "in Datei speichern" beläßt, viele parallele Skriptaufrufe für dieselbe Session-ID hat, und das Schreiben in die Datei verhältnismäßig lange dauert.
Welche Datenmenge dafür in der Realität in Frage kommt, habe ich allerdings noch nicht getestet. :) Ich schätze, dass es selbst mit zwei Megabyte noch keine Probleme gibt.
- Sven Rautenberg
-
Hello,
Welche Datenmenge dafür in der Realität in Frage kommt, habe ich allerdings noch nicht getestet. :) Ich schätze, dass es selbst mit zwei Megabyte noch keine Probleme gibt.
Das mit der Datenmenge habe ich schon mehrfach getestet und konnte eben feststellen, dass auf "normal ausgestatteten Servern" (meine Testrechner im LAN, 128MB und 256MB RAM, 700 und 800MHz Athlon, IDE PIO4) die 2MB Datenmenge im Block nicht das Problem sind, sondern nur, wenn man sie zeilenweise liest. Ist ja auch irgendwie logisch. --> Die Hardware hat Buffers (Cache), das OS hat Buffers und PHP puffert dann nochmal, bzw. schneidet immer nur Zeilen aus dem Buffer. In der Zwischenzeit wird der Hardware-Buffer von einem anderen Zugriff verwendet und der Actuator der Platte muss neu positionieren. Das kostet dann die Zeit.
Ärgerlich ist nur, dass es bei PHP4 keine Möglichkeit zu geben scheint, die redundanten Arrays ($_... und $HTTP_...) zu vermeinden.
Die Sache mit dem Mehrfachzugriff auf die Sessiondatei verstehe ich aber nicht ganz. Das kann doch eigentlich nur vorkommen, wenn man mit Frames arbeitet, dass unter einer SessionID mehrere zeitlich geschachtelte Anfragen vorliegen. Bei einem Include sind die Anfragen ja eingebettet und nutzen die gemeinsamen Variablen des Scriptes, da sie zu einem einzigen Request gehören.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Die Sache mit dem Mehrfachzugriff auf die Sessiondatei verstehe ich aber nicht ganz. Das kann doch eigentlich nur vorkommen, wenn man mit Frames arbeitet, dass unter einer SessionID mehrere zeitlich geschachtelte Anfragen vorliegen. Bei einem Include sind die Anfragen ja eingebettet und nutzen die gemeinsamen Variablen des Scriptes, da sie zu einem einzigen Request gehören.
Es hängt selbstverständlich alles von den Umständen ab.
Aber wer beispielsweise auf die Idee kommt, Bilder aufgrund einer Zugangsabfrage per Skript ausliefern zu lassen, der wird ebenfalls in diesen Problembereich eindringen.
- Sven Rautenberg
-
Hello,
Aber wer beispielsweise auf die Idee kommt, Bilder aufgrund einer Zugangsabfrage per Skript ausliefern zu lassen, der wird ebenfalls in diesen Problembereich eindringen.
Genau deshalb habe ich nochmal darüber nachgedacht. Das mache ich in meinem kleinen CMS so. Da gibt es eben "Bilder-Methoden", die von den Zugangsrechten im Stammscript abhängig sind. Das ist plausible, dass die dann erst nacheinander ausgeführt werden können, weil das Stammscript seinen Lock erst wieder aufgehoben haben muss.
Ist das denn sichergestellt, dass PHP da locks?
Dann müsste ich das aber wahrscheinlich in die "zu Fuß" geschriebene Session für "Auth401" auch einbauen. --Panik--
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Ist das denn sichergestellt, dass PHP da locks?
Bei der Session-Mechanik: Sicherlich.
Dann müsste ich das aber wahrscheinlich in die "zu Fuß" geschriebene Session für "Auth401" auch einbauen. --Panik--
Ja klar, wer Sessions zu Fuß regelt, und nicht mit session_start() und $_SESSION arbeitet, oder wer alternative Speichermethoden benutzen will, der muß sich ums Locking Gedanken machen, wenn er in Dateien speichert.
- Sven Rautenberg
-
Hallo Sven & Tom!
Interessanter Informationaustausch den Ihr beide hier führt, z.T. kann ich nur sagen: Hochinteressant! - was soviel heißt wie "ganz verstehe ich das aber nicht." ;-)
Anhand eines Beispiels habe ich eine Frage: Ich habe eine Seite mit einem Formular, wo der Anwender eine Datenbanktabelle ("Kundenstamm", "Lieferanten", ...) auswählt. Nach Absenden des Formulars kommt er auf eine Seite (immer die gleiche - egal welche Tabelle ausgewählt wurde) wo er diese Tabelle pflegen kann und die Seite richtet sich nach einer Sessionvariablen, welche den Tabellnamen gespeichert hat. Also z.B. "update SESSIONVAR set spalte1=x"
Selten gibts Probleme, können die damit zusammenhängen, daß der Anwender 2 Browserfenster offen hat?Besten Dank
Viennamade-
Hello,
Selten gibts Probleme, können die damit zusammenhängen, daß der Anwender 2 Browserfenster offen hat?
Das kann durchaus daran liegen. Ich knabber da auch immer noch an einer vernünftigen Vorgangsverwaltung, die dann natürlich als Modul oder Klasse eingebunden, alles automatisch regeln soll.
Mach Dir mal ein Zeit-Zustands-Diagramm von den Daten und markiere die Formularevents darin (Laden und Absenden). Dann wird es eigentlich ziemlich klar, dass man nicht nur eine Abgrenzung der Clients gegeneinander (Session) benötigt, sondern innerhalb der Session auch noch eine Abgrenzung der Vorgänge zueinander (Formular-ID)
Das Problem dabei ist, dass HTTP verbindungslos und zustandslos ist, also das Script (der Server) nicht merkt, wenn jemand seinen Vorgang einfach abbricht. Sonst könnte man einfach unterbinden, dass eine Doublette eines Vorganges angelegt wird, indem man einfach auf einen offenen Vorgang in der Session prüft. So wird man den User nur warnen können, dass er noch einen offenen Vorgang dieser Klasse hat und ihm ggf. ein Rollback des halben und eine Neueröffnung anbieten.
Ich denke, man kann das beliebig kompliziert gestalten. Ich suche aber noch nach einer einfachen Lösung.
Na, und wenn dann die Session eigentlich der einzige Ort ist, wo man diese Zustände vermerken kann, dann wird der Platz bald knapp. Auslagern der Daten ist auch nicht unbedingt sinnvoll, da sie für die Bearbeitung wieder in den RAM geholt werden müssen.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Hallo Tom!
Mach Dir mal ein Zeit-Zustands-Diagramm von den Daten und markiere die Formularevents darin (Laden und Absenden). Dann wird es eigentlich ziemlich klar, dass man nicht nur eine Abgrenzung der Clients gegeneinander (Session) benötigt, sondern innerhalb der Session auch noch eine Abgrenzung der Vorgänge zueinander (Formular-ID)
Danke für Dein Mail, habe es verstanden, auch, daß ich noch einen weiten Weg habe.
Beste Grüße
Viennamade
-
-
Hello nochmal,
um das nochmals zu differenzieren:
Bei den zeitlich geschachtelten Zugriffen auf die Sessiondatei handelt es sich um ein anderes Problem, als bei den zeitlich geschachtelten Mehrfachstarts eines Vorganges in verschiedenen Fenstern.
Es sind aber beide Probleme so wichtig und interessant, dass man sie lösen muss.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
-
-