Reverent001 Posted June 28, 2013 Report Share Posted June 28, 2013 Wie der Titel schon sagt, werden derzeit alle Informationen einer SESSION in die Datenbank geschrieben... Gibt es eine Möglichkeit, das zu unterbinden? Welche Nachteile hätte das für den Shop, den Benutzer oder vll auch mich? De Grüße Link to comment Share on other sites More sharing options...
mzanier Posted June 29, 2013 Report Share Posted June 29, 2013 Und wohin willst du die daten sonst schreiben ? Link to comment Share on other sites More sharing options...
Reverent001 Posted July 3, 2013 Author Report Share Posted July 3, 2013 Gegenfrage, warum werden Sie in einer Datenbank geschrieben? Mir entgeht derzeit noch der Sinn vom schreiben der SESSION in die DB?!?? Link to comment Share on other sites More sharing options...
mzanier Posted July 3, 2013 Report Share Posted July 3, 2013 Von der Performance her ist es fast egal ob session in DB oder in Filesystem. Die speicherung in die DB hat den vorteil das bei mehr als einem http node man ansonsten das Problem mit load balancing bekommt sofern auch eine Session im loadbalancer bei den nodes springt. Weiters hat es den vorteil das bei transaktions-starken shops eine eigene DB verbindung für die sessions angelegt werden kann (bzw auch ein eigener session cluster). Link to comment Share on other sites More sharing options...
Reverent001 Posted July 3, 2013 Author Report Share Posted July 3, 2013 Okay, verstand! Gerade für Punkt 2 Sicherheit eine feine Sache! Ich habe halt das Problem, dass wir einen Shop betreiben, zwar mit relativ geringer Anzahl an Produkten, jedoch mit vielen Infos zu diesen. Hinzu kommt dass der gesamte Bestellprozess modifiziert wurde, sodass eine Session schonmal recht groß werden kann und die Datenmenge die in die Datenbank geschrieben wird bis an die 2MB ran kommt (xt_sessions). Auf meinem lokalen Testsystem war das Ergebnis nicht so schön => Datenbank hat sich verabschiedet. Auf dem Live-System dagegen sieht es etwas anders aus. Bisher konnte ich eine Maximale, ich nenn es mal "Session-Time" von 8 Sekunden pro klick feststellen, was noch erträglich ist. Bei etwas langsameren Internetleitung wird es aber auch hier schon etwas problematischer! Naja muss mal schauen was noch unabhängig von der SESSION zu optimieren ist! Danke aber für die Auskunft... Link to comment Share on other sites More sharing options...
mzanier Posted July 3, 2013 Report Share Posted July 3, 2013 Was machen 2MB in der session ? Da wurde aber wohl einiges zu tode "modifiziert". Link to comment Share on other sites More sharing options...
Reverent001 Posted July 4, 2013 Author Report Share Posted July 4, 2013 Naja zu Tode würde ich jetzt nicht behaupten, es musste ne "schnelle" Lösung her, die mit Sicherheit optimiert werden kann! Wäre jetzt alles etwas zu kompliziert das hier zu erklären! EDIT: Gerade mal am live-System nachgeschaut. in der Tabelle xt_session2 gibt es 109 Einträge die 6,4MB belegen..... ist doch schon etwas viel! Link to comment Share on other sites More sharing options...
Alex@4tfm Posted July 6, 2013 Report Share Posted July 6, 2013 Also ich würde mal sagen dein Problem ist eher, dass du diese großen Daten woanders zwischenspeichern solltest. Ich meine, 2MB... Was hast du den da drin? Text od. Bild? Bild evtl. zwischenspeichern und einen Link in die Session...? Link to comment Share on other sites More sharing options...
Reverent001 Posted July 9, 2013 Author Report Share Posted July 9, 2013 Hehe schön wäre es... aber nein Bilder würde ich nicht in eine Session speichern! Es handelt sich unter gewissen Umständen um drei Warenkörbe pro Session. Bei bis zu 250 Artikelpositionen pro Warenkorb und eine Produktinformationserweiterung durch das ERP um 3 weitere Beschreibungsfelder sowie etliche Merkmalfelder wächst da eine Session schon mal sehr schnell an. Bin das Ganze aber gerade kräftig am überarbeiten um eventuell doch nur mit einem Warenkorb arbeiten zu müssen! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.