SESSION zu groß

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • SESSION zu groß

    Hallo,

    hat jemand Erfahrung im "tunen" von php Aplikationen, deren Session zu groß geworden ist?

    Ich habe hier eine Applikation übernommen, die so viel in der Session speichert, das die Performance der Seite darunter leidet.

    Die Applikation zu umzuschreiben, das einfach weniger Daten in der Session gespeichert werden, ist zu viel Aufwand.

    Gibt es andere Möglichkeiten? Kann man die Session irgendwie packen?

    Macht es Sinn (ist es schneller), einen eigenen Session-Handler zu schreiben und die Session-Daten in einer Datenbank zu speichern?

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • Hallo,

    eine Lösung für mein Problem habe ich bis jetzt nicht gefunden, aber ich kann zumindest schon mal über ein negativ Ergebnis berichten.

    Normalerweise wird die Session ja im Dateisystem des Servers gespeichert.
    Eigentlich sollte es schneller gehen, die Session aus einer Datenbak auszulesen. Tut es aber nicht.

    Ich habe mir jetzt ein eigene Klasse geschrieben, die einen Session-Handler mit bringt, der die Session-Verwaltung komplett über die Datenbank regelt, aber das hat nichts gebracht. Es dauert immer noch fast 9 Sekunden, bis die Session eingelesen und deserialzed ist...

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • Hi, ich arbeite auch mit Sessions, sogar jetzt richtig viel, dein Post macht mir da etwas sorgen mal ein paar fragen:

    Wie groß ist seine Session und woher weißt du wie Groß die ist. (pro user versteht sich)

    Und vorallem was speicherst du da alles ab?


    Macht mir schon etwas kummer nicht das beim 3 nutzer mein System zusammen klappt ... :shock:

    Sessions über die Datenbank habe ich noch nicht versucht, weil ich nicht weiß ob das bei mir sinnvoll ist... Habe eine Datenbank mit ca 23 Tabellen und a 17000-25000 Datensätzen ...

    so long JFoX
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • "JFoX" schrieb:


    Wie groß ist seine Session und woher weißt du wie Groß die ist. (pro user versteht sich)

    Und vorallem was speicherst du da alles ab?


    Macht mir schon etwas kummer nicht das beim 3 nutzer mein System zusammen klappt ... :shock:

    Sessions über die Datenbank habe ich noch nicht versucht, weil ich nicht weiß ob das bei mir sinnvoll ist... Habe eine Datenbank mit ca 23 Tabellen und a 17000-25000 Datensätzen ...

    so long JFoX


    Also meine Session ist 1.5 - 3.2 MB groß. Die Session-Daten werden als ganz normale Text-Files auf dem Server abgelegt. Wenn man Zugriff auf den Server hat, kann man die Größe daher ganz leicht sehen.

    Hat man keinen Zugrif hilft z.B. ein serialize($_SESSION) und den daraus resultierenden String einfach irgendwo hin speichern.

    Die Session ist ja User bezogen, d.h. pro User gibt es eine Session-Datei. D.h. die Session wird nicht größer wenn mehrer User auf Dein System zugreifen.

    Das Hautpproblem bei einer großen Session ist auch nicht das Lesen der Session Daten, sondern das serializen bzw unserializen der Session-Daten.

    Von daher hilft ein Speichern in der Datenbank nicht viel. Auch das kompremieren der Session bringt daher nichts.

    Bin durch viel Ausprobieren in den letzten Tagen also schon etwas schlauer geworden.

    Dadurch das eigentlich nur Objekte in meiner Session gespeichert werden, konnte ich die Größe jetzt schon etwas verringern, in dem ich durch die "__sleep()" Methode die Objekte vor dem Serializen aufräume. Das hilft zwar nicht viel beim Serializen der Session, aber das Unserializen wurde dadruch wesentlich schneller (von 7 Sekunden auf 2 Sekunden).

    Falls jetzt irgend jemand fragt warum ich immer von serializen/unserializen rede:

    Die Session wird als String gespeichert. daher müssen die Session-Daten vor dem Speichern serialized werden. Beim session_start wird das der "Session-String" wieder geladen und unserialized.

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • Ah, ok ich wusste nicht genau ob die Datei auf dem Server die wikrliche Session-Größe ist.

    Aber danke für die Informationen, ich werde mir das alles nochmal durch den Kopf gehen lassen und testn vieleicht kann man sich dann irgendwie ergänzen. :)
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • hi mel :)

    welche art daten werden den bei dir in den sessions gespeichert?

    wenn es nur einfache strings / werte sind, wäre es eigentlich relativ einfach die daten in ner db zu speichern. hätte auch den vorteil das man immer nur die daten abruft die man auch brauch, und nicht irgendwelche daten die von seite zu seite durchgeschliffen werden.

    sessions sind ja imho nur dafür da, um nen user über mehrere seiten (rel.) eindeutig wieder zu erkennen, wie in nem shop system z.b. evtl noch n paar daten die die sicherheit erhöhen aber sonst wüsste ich jetzt nicht was man unbedingt in ner session speichern müsste wenn man ne db nutzen kann...


    mfg da BendIt
    .:Reden Ist Schweigen und Silber Ist Gold:.

    real programmers don't comment their code: if it was hard to write, it should be hard to read!

  • Hallo,

    wie ich ja schon geschrieben habe, werden in erster Linie Objekte in der Session gespeichert. Das ganze ist bein recht komplexes, hierarchisches System und ich kann die grundlegende Funktionlität, das die Objekte in der Session gespeichert werden auch nicht ändern, das wäre ein wahsinns Aufwand...

    Mal sehen, vieleicht fällt mir noch was sinnvolles übers Wochenende ein...

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • "d0nUt" schrieb:

    Also mir widerstrebt es auch solche Session Mengen zu speichern.
    Du könntest das Objekt doch eben in der Datenbank speichern und dem User so zur Verfügung stellen.

    Ob du $viele_daten = $_SESSION['data'] verwendest oder eben

    Quellcode

    1. $viele_daten = getObjectFromDB($_SESSION['id']);
    macht für mich kein Unterschied.


    Das kommt auf die Anzahl der Datenbankeinträge an. Wir sprechen hier von einem Projekt das mitlerweile fast 1 Million "Objekte" in der Datenbank hat.

    Für ein "einfaches" Projekt hast Du sicher recht, aber bei einer komplexen Anwendung, wo es dann evtl. auch noch mehrere DB Anfragen braucht, bis das Objekt komplett geladen ist sieht das anders aus.

    Und dann kommt ja hinzu, das in der Session nicht ein einzelnes Objekt gehalten wird, sondern evtl. über tausend Stück, ja nach Hierarchie-Struktur in der ich mich gerade befinde...

    Mir gings ursprüngliche eigentlich nur darum, ob es evtl. irgend welche Tricks gibt, wie man eine große Session besser in den Griff bekommt, aber momentan sieht es nicht so aus...

    Einen Teilerfolg habe ich ja dank der __sleep Methode ja schon erzielt.

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • Ich weis ja nicht um was für ein projekt es sich bei dir handelt...

    aber für mich klingt das eher nach einem eher schlecht gecodeten projekt.

    session sind und waren eigentlich nie dafür gedacht um so große daten zu handeln.

    wäre es nicht sinnvoller sich über eine komplette neu entwicklung gedanken zu machen?

    weil performant würde ich das nicht nennen... und ich bezweifell ehrlich gesagt das webanwendungen für diese datengrößen konzipiert wurden.

    sry... will dich oder den der das gecodet hat nich angreifen oder so... aber sagst ja selber
    das die performance unter der "Datenlast" leidet...


    mfg da BendIt
    .:Reden Ist Schweigen und Silber Ist Gold:.

    real programmers don't comment their code: if it was hard to write, it should be hard to read!

  • "BendIt" schrieb:

    Ich weis ja nicht um was für ein projekt es sich bei dir handelt...
    aber für mich klingt das eher nach einem eher schlecht gecodeten projekt.
    wäre es nicht sinnvoller sich über eine komplette neu entwicklung gedanken zu machen?


    Tja, das ist halt ein typisches größere IT-Projekt, was über die Jahre gewachsen ist...

    Eine Neuentwicklung kommt aus Kostengründen nicht in Frage ;)

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • wieso sollte es aus kostengründen nicht in frage kommen ?

    ist nicht entscheidend was du mit diesem projekt erreichen willst ?
    da muss man investieren oder sich ernsthaft gedanken machen ob dieses projekt sinn hat ;)
    sry will dich jetzt hier nicht in irgendeiner weise angreifen oder so

    aber wenn du wirklich performance probleme hast dann würde ich mir dir mühe machen das ganze script auf datenbanklösung umzuschreiben denn wenn so eine Session 2 Megabyte groß ist und mal angenommen da sind 1000 benutzer eingeloggt.... das sind gute 2 Gigabyte nur temporärer müll oder entweder nicht ???
    deshalb versuch das ganze auf datenbank zu konzipieren ist nicht ganz so HDD lastig für den server...

    ich z.B. verwende sessions nur um da kurz ne id, oder nen nickname etc. zu speichern.. und nicht tausende objekte ^^

    mfg: marcel
    Beste Grüße,
    M4rc3L-XCN

  • wieso sollte es aus kostengründen nicht in frage kommen ?


    Weil die Kosten einer Neuprogrammierung höher sind, als die einer schlechten Performance.


    ist nicht entscheidend was du mit diesem projekt erreichen willst ?


    Wenn es sich dabei um ein privates Projekt handelt mittlerer Größenordnung magst du vielleicht einen interessanten Punkt ansprechen, aber wenn es um komerzielle Proejtek geht, zähltin der heutigen Welt nur noch der Kostenpunkt!
    [OFFTOPIC]
    Deswegen greift fast niemand mehr auf Individualsoftware zurück, sondern nutzt Standardsoftware.
    [/OFFTOPIC]

    ich z.B. verwende sessions nur um da kurz ne id, oder nen nickname etc. zu speichern.. und nicht tausende objekte ^^


    steht im Gegensatz zu

    das ist halt ein typisches größere IT-Projekt


    ;)


    Du kannst halt nicht pauschal sagen (wenn du in ner Firma o.ä. sitzt): hier, das Programm is unperfomant, lass mal neues coden.
    Letztendlich gings im Topic auch über Optimierungsmöglichkeiten... Nur, um das noch mal ins Gedächtnis zu rufen :)

  • "marcel" schrieb:

    wieso sollte es aus kostengründen nicht in frage kommen ?

    ist nicht entscheidend was du mit diesem projekt erreichen willst ?
    da muss man investieren oder sich ernsthaft gedanken machen ob dieses projekt sinn hat ;)


    Wie BennyBunny ja schon geschrieben hat, liegt die Entscheidung für so etwas nicht immer beim Programmierer...

    Die Neuentwicklung eines Systems, was aus ein paar hundert Dateien Code besteht kann schon recht kostspielig werden.

    Auch wenn ein Neuanfang bei dem System sicherlich sinnvoll wäre, und obwohl da eine größere Firma dahinter steckt, die das System weltweit einsetzt, wird es wohl nie dazu kommen.

    Also muss man als Programmierer halt das Beste daraus machen und versuchen das ganze so weit zu optimieren, das es auch weiterhin vernünftig läuft.

    70abc
    We raise hopes, here ... until they're old enough to fend for themselves.
    - Mike Callahan

  • Ich glaube das Problem war eigentlich schon zur Zufriedenheit gelöst, aber da ich in der Zwischenzeit auch was neues gelernt habe, gehe ich nochmal auf mein Posting von oben ein.

    "d0nUt" schrieb:

    Du könntest das Objekt doch eben in der Datenbank speichern und dem User so zur Verfügung stellen.


    Deine Antwort darauf war, dass verschiedene Sachen in verschiedenen Tabellen liegen.
    Tatsache ist, dass $_SESSION aber auch nur ein einziges Array ist. Es ist also durchaus "möglich".
    Wenngleich es bei einem großen Projekt und einem starr eingecodetem $_SESSION schon eine größere Arbeit sein kann. Somit... wie du willst... ;)

    Jedenfalls solltest du dir, falls du es noch nicht kennst, mal Propel anschauen. Das ist zur Abbildung von PHP-Klassen in einer relationalen Datenbank.
    http://www.professionelle-softwareentwicklung-mit-php5.de/erste_auflage/db.propel.html