|
|||
|
Hallo,
seit ich mit dem Shop online bin erhalte ich total Viele Emails vom Shop in diesem Format: Code:
mysql error: [2006: MySQL server has gone away] in EXECUTE
("UPDATE xt_sessions2 SET expiry = NOW() + INTERVAL 1440 SECOND
,expireref='', modified = NOW() WHERE /*! BINARY */
sesskey = 'c04d2d16aabbff612e1e238aXXXXXXXX' AND expiry >= NOW()")
Mittlerweile 22 Emails innerhalb von nicht mal 2 Stunden. Was ist das? V.G. Micha |
|
|||
|
Kann die Abfrage denn nicht anders gestaltet werden? Das solche Fehler nicht auftreten können?
Hat das was damit zu tun, das in der dreier Version die Sessions in Daten geschrieben werden konnten (konnte man ja bei Installation auswählen) und in Veyton die Sessions immer in die DB geschrieben werden? Hoster (all-inkl) ist da auch schon dran, aber ich vermute, der wird da soviel auch nicht ausrichten können. V.G. Micha |
|
|||
|
Hallo,
folgende Meldung hat mir all-inkl.com dazu geschrieben: permanente DB Verbindungen sind grundsätzlich schlecht. Ihnen stehen 25 gleichzeitig offene verbindungen zur verfügung, wenn nun 25 User im Shop sind ist bei permanenten DB Verbindungen Schluss weil diese ja die ganze Zeit offen gehalten werden. Ich empfehle Ihnen daher die sessionverwaltung auf Dateibasierend umzustellen. Kann mir jemand was dazu sagen? Benötigt der Shop wirklich für die Sessions Persistente Datenbankverbindungen??? V.G Micha |
|
||||
|
Nein, es wird keine persistente Verbindung für die Session DB gemacht.
__________________
xt:Commerce Helpdesk xt:Commerce Blog xt:Commerce Warenwirtschaft ### ![]() Offene Stellen bei xt:Commerce! xt:Commerce stellt ein ### |
|
|||
|
Danke für die schnellen Antworten
![]() In dem Fall sollte es ja aber egal sein wie viele Verbindungen der Hoster zulässt. Ich werden das mal weiterleiten das der Shop keine persistente Verbindung nutzt. Mal schauen ![]() V.G. Micha Geändert von mizzy (10.03.2009 um 09:03 Uhr) |
|
|||
|
Hallo,
also all-inkl. hat mir nun folgendes mitgeteilt: Die Techniker haben nun auf die Datenbank 3 Indizes gesetzt auf: ALTER TABLE `xt_products` ADD INDEX `all_inkl_manufacturers_id` (`manufacturers_id` ) ; ALTER TABLE `xt_orders_products` ADD INDEX `all_inkl_orders_id` (`orders_id` ); ALTER TABLE `xt_orders_products` ADD INDEX `all_inkl_products_quantity` (`products_quantity` ); Informationen zu Indizes finden Sie unter folgendem Link: http://dev.mysql.com/doc/refman/5.1/...n-indexes.html Dies sollte zur Entlastung und Verbesserung der MySQL Abfragen führen. Diese können jedoch jederzeit wieder gelöscht werden. 150 Kunden auf einem Shop sind auch in kleineren Tarifen problemlos möglich. Die Auslastung hier muss also andere Ursachen haben. Ebenso wird der von Ihnen genutzte Shop auch von anderen Usern genutzt. Die Begrenzung von 25 gleichzeitigen Datenbank Abfragen sollte hier auch keine Probleme verursachen da bei ordnunsggemäßer Programmierung die Datenbank Abfragen nach Nutzung wieder geschlossen werden. Bitte testen Sie einmal ob nach dem Setzen der Indizes das Problem behoben wurde. Also was soll mir gesagt werden? So recht verstehe ich das nicht mit den Indizies. Und ich versteh auch nicht so ganz warum wieder von den 25 gleichzeitigen Datenbankabfragen gesprochen wird. Ich dachte der Shop nutzt keine persistente Verbindung. V.G. Micha PS: Nachtrag, scheinbar hat auch das nichts genutzt. Denn die Datenbankfehleremails des Shops kommen weiterhin. Und dieses Mal habe ich den selbst mal absichtlich verursacht. Das geht indem man einfach mal sich anmeldet, nen Produkt in den Warenkorb legt und dann mal so 10 bis 15 Minuten nichts macht, z.B. wo anders surfen oder Emails schreiben. Dann geht man mal wieder in den Shop, will auf den Warenkorb klicken bzw. Bestellvorgang einleiten und was muss ich da sehen, es sind auf einmal keine Artikel mehr im Warenkorb weil die Session gelöscht wurde. Auch bin ich gleich nicht mal mehr eingeloggt. Aber jetzt zum eigentlich komischen: Log ich mich aus, aus dem Shop mach Firefox zu und log mich wieder ein, ist doch glatt der Warenkorb wieder da, der vorher weg war. Also woran liegt das nun am Shop oder am Hoster? Wobei ich aufgrund meiner Fehlersuche fast denke, dass das Problem Shopseitig besteht. Zumal ja all-inkl. nicht irgendso ne Billighoster Schmiede ist :-) Zumindest nicht der Business Tarif. Geändert von mizzy (10.03.2009 um 20:23 Uhr) |
|
|||
|
So noch einmal neues vom Hoster:
in der Datei ./xtFramework/library/adodb/drivers/adodb-mysql.inc.php wurden noch mysql_pconnects verwendet diese haben wir einmal abgeändert. Desweiteren haben wir noch 2 Indizes gesetzt die aus der Analyse des Slowqueries.logs ALTER TABLE `xt_plugin_products` ADD INDEX ( `plugin_status` ) ALTER TABLE `xt_languages` ADD INDEX ( `sort_order` ) V.G. Micha |
|
||||
|
ja in der datei gibt es eine funktion für den pConnect, aber die wird vom shop nicht verwendet
![]() sowohl die verbindung zur shopdatenbank und die verbindung zur session datenbank fahren mit einem normalen connect, und keinen pconnect.
__________________
xt:Commerce Helpdesk xt:Commerce Blog xt:Commerce Warenwirtschaft ### ![]() Offene Stellen bei xt:Commerce! xt:Commerce stellt ein ### |
![]() |
| Lesezeichen |
| Stichworte |
| emails, error, massig, shop, sql |
| Themen-Optionen | |
| Ansicht | |
|
|
Ähnliche Themen
|
||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Shop Von Einem Server Zum Anderen Verschieben | Shinzon | Installation und Konfiguration | 18 | 17.01.2005 03:29 |