Hallo, ich habe eine Frage. Ab dem 15 Artikel wird der Warenkorb sehr langsam. Wenn man dann einen neuen Artikel in den Warenkorb legt, dauert das über 10 Sekunden, ist das normal? Plugin habe ich schon an- und abgeschaltet, Template auf das Originale umgestellt etc… FirePHP sagt mir nun, dass es es Datenbank ist: Database Querys (932 @ 13.05776 sec) time count sql 12.88443 153 UPDATE s_order_basket SET quantity = ?, price = ?, netprice = ?, currencyFactor = ?, tax_rate = ? WHERE id = ? AND sessionID = ? AND modus = 0 Benchmark Controller (13.49550 sec) Action_PostDispatch 11.75 mb 13.44965 - 38 Artikel im Warenbkorb - MySQL 5.5.42 Gibt es noch irgendwelche Möglichkeiten um das zu beschleunigen?
Poste mal die Hardware Konfiguration von deinem Server. Habe es auch mal ausprobiert, es wird immer länger umso mehr Artikel im Warenkorb sind, bei dauert es nach dem 17. Artikel fast 5 Sekunden bis eine Rückmeldung kommt, und wenn ich das ganze über das Handy probiere, dann wird es noch langsamer. Woran das liegen kann weiß ich nun auch nicht, habe das Problem mit dem immer langsamer werden auch. Shopware 4.3.2 Intel® Celeron® CPU G530 @ 2.40GHz, 2 Kerne, 4GB Ram, 6Gbit Webanbindung, Raid 1, 1TB
Wir haben das gleiche Problem. Unsere Bestellung bestehen in der Regel immer aus mehr als 15 Positionen. Uns wurde es mal so erklärt, dass Shopware von Haus aus alle Preise jedes Mal neu berechnen muss und somit die Anfragezeit sich jedes Mal erhöht. Es ist also “normal” …
Also „normal“ sollte das eigentlich nicht sein - schreckt ja alle Kunden ab, wenn die länger als 10 Sekunden warten müssen. Hier muss von Shopware eine saubere Lösung kommen. Für mich gehört das zum Thema Usability.
Hallo, ich leide aktuell unter selbigem Problem und unsere Warenkörbe bestehen ebenfalls aus 10 Artikeln aufwärts. Der Shop wird nahezu unbenutzbar wenn ein warenkorb voller und voller wird. Hat jemand schon eine Lösung?
Ich habs gerade in meinem Shop ausprobiert mit ca 30 Artikeln und bei mir gehts eigentlich sehr zügig. Denke mal nicht, dass das an SW liegt, mehr an einer Einstellungssache oder div. Plugins. @Headake - war gerade in Deinem Shop mal testen, da gehts schon bei ein-zwei Artikeln langsam los. Auch hast Du keine weiter- und zurück Funktion zum nächsten Artikel. Das ist noch nerviger, da man zur Kategorie zurück muss. Ein Umsatzkiller und ich wäre direkt wieder weg wenn es so umständlich ist. 
Zitat vom Shopware-Support: “Hier liegt eindeutig eine Fehlkonfiguration des MYSQL-Servers vor.” Ach wirklich? Dann gehen wir der Sache mal auf den Grund: /engine/core/class/ - beim puren Aufruf vom Warenkorb mit nur einem Artikeln werden hier pro Artikel über 20 Updates durchgeführt - ausgelöst wird dies durch die Funktion sGetBasket() und foreach ($basketData as $basketContent) in sBasket.php - sGetBasket() wird aufgerufen durch sAdmin.php function sGetPaymentMeanById() - sGetPaymentMeanById() wird aufgerufen durch sAdmin.php function getUserShippingData() - vermutlich wird die Funktion sGetBasket() noch durch weitere andere Funktion aufgerufen Wird der Warenkorb mit nur einem Artikel aufgerufen, dann macht Shopware diese Abfragen: 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601435 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601435 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sAdmin.php sGetPaymentMeanById() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() 1426601436 /engine/core/class/sBasket.php sGetBasket() (die Zahl am Anfang ist der Timestamp) In diesem Falle hat das System 24x “UPDATE s_order_basket…” durchgeführt. Warum werden überhaupt beim puren Aufruf vom Warenkorb solche Update-Orgie gemacht? Das hat mit Performance nichts zu tun und ist die schlechteste Lösung überhaupt. Ein Update sollte NUR durchgeführt werden, wenn man die Anzahl ändert, sonst nicht - so geht Performance! Und das war jetzt nur 1 Artikel! Bei weiteren Tests mit 20 Artikeln wurden im Durchschnitt 500 Updates gemacht! Die Wartezeiten schwankten zwischen 20 und 40 Sekunden. PS: Diese merkwürdige und unsinnige Verhalten steht mit keinem Plugin in Verbindung. Während der Testphasen haben wir alle Plugins deaktiviert, jedoch an den grauenhaften Wartezeiten im Warenkorb hatte sich nichts geändert. Für diese Analyse müssten wir nun 999,99 von Shopware verlangen, weil das Suchen eine echte zeitaufwendige Angelegenheit ist - Zeit die wir eigentlich nicht haben, und bei einer bezahlten PE-Version auch nicht eingeplant ist. Sorry, aber ich bin eben etwas frustriert.
[quote=“R4M”]Bei weiteren Tests mit 20 Artikeln wurden im Durchschnitt 500 Updates gemacht! Die Wartezeiten schwankten zwischen 20 und 40 Sekunden.[/quote] Ohne das zugrunde liegende Konzept von Shopware beurteilen / verurteilen zu wollen: wenn 500 Updates 20 bis 40 Sekunden dauern, dann -ist- dein Server falsch konfiguriert. Ein häufiges Problem: Schreibzugriffe auf die DB werden direkt auf die Platte durchgeschrieben. Viele Grüße
[quote=“Aquatuning GmbH”] Ohne das zugrunde liegende Konzept von Shopware beurteilen / verurteilen zu wollen: wenn 500 Updates 20 bis 40 Sekunden dauern, dann -ist- dein Server falsch konfiguriert. Ein häufiges Problem: Schreibzugriffe auf die DB werden direkt auf die Platte durchgeschrieben. [/quote] Wenn 500 Updates gemacht werden, sind das 480 zu viel. Da ist es völlig Wurst wo der Schreibzugriff geschieht, es dauert so oder so zu lange.
Die Frage ist ja, welche Funktionen rufen wiederum die getBasket() auf. Die getBasket() liefert ja viele Informationen, welche von anderen Funktion benutzt werden. Z.B Gutschein, Versandkosten, Riskmanagement etc. Alle diese Module brauchen den aktuellen Warenkorb um weitere Bedingungen zu prüfen oder verarbeiten. So einfach bekommst du das Problem nicht gelöst. Sicher könnte man den ein oder anderen Aufruf weglassen bzw. anders lösen.
[quote=“DieKonkurrenz”]Wenn 500 Updates gemacht werden, sind das 480 zu viel. Da ist es völlig Wurst wo der Schreibzugriff geschieht, es dauert so oder so zu lange.[/quote] Sind wir auf der Suche nach einem Schuldigen - oder nach einer Lösung?! Viele Grüße
Um Missverständnisse vorzubeugen - wir reden hier nur vom Aufruf des Warenkorbes. Keine Änderungen bei Artikel-Anzahl, kein weiterer Bestellvorgang, kein Einsatz von irgendwelchen Plugins und von SW PE 4.3.3. Also der Kunde hat seine Artikel in den Warenkorb gelegt, und geht nun in den Warenkorb. Jetzt werden solche Querys ausgelöst: [quote] UPDATE s_order_basket SET quantity = ?, price = ?, netprice = ?, currencyFactor = ?, tax_rate = ? WHERE id = ? AND sessionID = ? AND modus = 0 [/quote] (function sUpdateArticle) Wenn ich also nichts an der Artikel-Anzahl ändere welchen Sinn haben diese Updates? Kann mir das mal ein Shareware-Programmeier erklären? Ich verstehe es jedenfalls nicht. Und wenn schon dieses Updates gemacht werden muss (aus welchen Gründen auch auch immer) dann pro Artikel nur einmal. Und wenn hier die Updates sinnvoll eingesetzt werden, und sich die Updates im normalen Rahmen bewegen, dann brauchen wir gar nicht über Ladezeiten reden, weil diese Thema dann gar nicht bestehen würde!!! Und dann könnte man zurecht sagen “he Shopware hat in Sachen Performance wirklich etwas drauf”, aber so sicherlich nicht. Und aktuell bin ich wirklich etwas sehr sauer. Nachdem wir nun über tausend Produkte eingepflegt haben, Templates und Plugins angepasst haben wird uns vorgeschlagen eine neue frische Shopware-Version zu installieren. Wenn Shopware auf großen Root-Servern nicht funktioniert, ist das System einfach nicht zu empfehlen. Und ich rede hier hier fetten Root-Servern! Sorry, aber an dieser Stelle ist jedes andere Shopsystem besser dran. Ja sogar der alte XT-Commerce oder OXID eShop ist bei der Ansicht Warenkorb 10x schneller. Ein Vorschlag: Die Shopware-Programmierer setzen sich auf ihren Hosenboden und suchen nach einer sauberen Lösung damit diese Update-Orgie aufhört bzw. nur dann gemacht wird, wenn es auch nötig ist und NUR die Artikel die es auch betrifft. Also 500 Querys bei 20 Artikeln ist nicht tragbar! Und ich kann mir nicht vorstellen, dass diese Performance-Schleuder bei Shopware gewollt ist. Wir prüfen warum die Update-Querys so lange dauern. Eventuell wird der Status vom Update vom Shop-System noch abgefragt? Denn ein reines Update Query ist in Null-Komma-Nichts verarbeitet, es sei denn es wird nach jedem Update noch der Status vom Update geprüft. Mit freundlichen Grüßen genervter Shopware-Kunde …
Hallo, ich kann dein Problem nicht nachvollziehen. Habe eben 50 verschiedene Artikel in den Warenkorb bei mir gelegt und die Ladezeit zum Anzeigen des Warenkorbs war bei 1,6 sek lt. Firebug (1 Artikel 650ms) was ich als Kunde „noch ok“ finde. ggf. liegt es doch an deinen Servereinstellungen. Was allerdings auch helfen könnte ist, wenn du das Dropdown-Menü für die Menge durch ein Textfeld ersetzt. (Spart je Artikel ca. 100 Zeilen Code) Wir verwenden einen Cloud-LVE-L von Hostianer. Shopware 4.3.4 PE mit Conexco-Template.
[quote=“R4M”]Wenn Shopware auf großen Root-Servern nicht funktioniert, ist das System einfach nicht zu empfehlen.[/quote] Es kommt -immer- nicht nur auf die Hardware an - sondern auch auf die Konfiguration. Dein Server ist schlichtweg falsch konfiguriert - siehe dazu meinen Hinweis aus dem letzten Post [quote=“R4M”]Ein Vorschlag:[/quote] Kannst / möchtest du so lange warten, bis Shopware den kompletten Warenkorb umgeschrieben hat? Wäre das eine Lösung für dich? [quote]Wir prüfen warum die Update-Querys so lange dauern.[/quote] Das ist genau der richtige Ansatz. Viele Grüße
Ich denke das Problem muss erst mal an der Wurzel behoben werden. Die Servereinstellungen sind jedenfalls nicht für 500 Updates-Query verantwortlich. Ich denke bei dieser Tatsache kann mir zugestimmt werden oder? [quote] Wir verwenden einen Cloud-LVE-L von Hostianer. Shopware 4.3.4 PE mit Conexco-Template. [/quote] Frage: Habt ihr gleich auf Shopware 4.3.4 aufgesetzt oder per Upadtes auf diese Version gebracht? Wir hatten am Anfang CE-Version 4.2.x oder so. Erst später per Lizenz daraus eine PE-Version gemacht und zuletzt auf 4.3.3 Update gefahren. Wie auch immer, unsere Shopware-Version wurde hier von dieser Website runter geladen. Nichts verändert oder sonst rumgefummelt. Und hier passieren solche Dinge:
Im Screen gut zu erkennen, dass unter dem Update-Query noch ein SELECT (auch über 400mal) steht, was aber deutlich schneller geht. Ich habe dafür einfach keine Erklärung!
[quote=“R4M”]Die Servereinstellungen sind jedenfalls nicht für 500 Updates-Query verantwortlich[/quote] Noch einmal: der Shop feuert bei deinem Warenkorb 500 Updates - richtig. Wenn dein Server aber 20 bis 40 Sekunden braucht um diese abzuarbeiten, dann ist er falsch konfiguriert. Ein häufiger Fehler: Schreibzugriffe werden direkt auf die Platte durchgeschrieben. [quote]Im Screen gut zu erkennen, dass unter dem Update-Query noch ein SELECT (auch über 400mal) steht, was aber deutlich schneller geht[/quote] Richtig - weil hier 1. das caching von Mysql greift und 2. kein Zugriff auf die Platte stattfindet. Viele Grüße
Deine Konfiguration kann nichts für die 500 Update-Querys. Wir hatten eine 4.1.x CE auf eine 4.1.x PE geupgradet und mit der Zeit sind wir nun bei der 4.3.4 angekommen. Ich würde Shopware einfach mal komplett neu installieren. Könnte helfen.
[quote=„R4M“]Ich denke das Problem muss erst mal an der Wurzel behoben werden. Die Servereinstellungen sind jedenfalls nicht für 500 Updates-Query verantwortlich. Ich denke bei dieser Tatsache kann mir zugestimmt werden oder? [/quote] Dem widerspricht ja auch niemand. Die eigentlich wichtigere Frage ist aber, wie Auquatuning auch schon erwähnt hat: Warum macht das bei dir Probleme und bei anderen nicht? So wie ich Shopware bisher kennengelernt habe haben die das Problem auf dem Schirm und sofern es keine guten Gründe dafür gibt es so zu machen wie es gerade gemacht wird wird es auch behoben und optimiert. Sowas anzupassen geht aber nicht immer von heute auf morgen. Und insbesondere wenn es in 99% (einfach mal aus der Luft gegriffen) der Installationen keine Probleme bereitet gibt es sicherlich dringendere Baustellen.
[quote] Wenn dein Server aber 20 bis 40 Sekunden braucht um diese abzuarbeiten, dann ist er falsch konfiguriert. [/quote] Auf dem Server laufen rund 300 Domains mit Joomla, Wordpress, Typo3 etc. Und keines von diesen verursacht eine so hohe Anzahl von Querys - deren Sinn ich nicht verstehe. Das Problem sollte erst mal an der Wurzel behoben werden, und das ist hier Shopware. Wenn die Querys optimierter laufen würden, würde es diesen Thread hier gar nicht geben 
Es wäre uns nie aufgefallen [quote] Ich würde Shopware einfach mal komplett neu installieren. Könnte helfen. [/quote] Wenn das so einfach wäre!!! Wir haben schon genug Geld + Zeit + Aufwand + etliche Support-Anfragen investiert. Wir reden wir von sehr viel Arbeit die wir noch mal machen müssten. Nein, bei diesem Gedanken fallen mir die Haare aus
Hallo zusammen, das Thema wurde auch bereits im Support ausgiebig besprochen. Shopware ist gerade dabei den Code zu refaktorieren und in einer der nächsten Updates kommt auch sicherlich der Warenkorbprozess auf die Waage. Wie hier auch schon von anderen erwähnt, erfolgt dies nicht kurzfristig und das ist auch garnicht möglich. Wenn es hier eine “einfache” Optimierung gäbe, wäre sie schon in den Core mit eingeflossen. Entsprechend ist der derzeitige Stand erstmal gegeben und man muss den Server entsprechend daran anpassen. Unabhängig von der softwareseitigen Optimierung dauert die Update-Abfrage aber auch einfach zu lange in dem Beispiel. Vergleichbare Systeme (mit Mindestanforderungen von Shopware) arbeiten in diesem Szenario deutlich schneller und verarbeiten die 500 Querries in unter 0,04 Sekunden. Entsprechend muss es hier - wie bereits beschrieben - ein Konfigurationsproblem geben. Natürlich gibt es in diesem Bereich sicherlich optimierungsbedarf, dies wird auch keinesfalls von uns verschwiegen, das Hauptproblem ist hier aber einfach ein anderes. Und um einen vernünftig schnellen Warenkorb zu bekommen, benötigt man keinesfalls einen Root-Server. Selbst die Standardkonfiguration bestimmter Linux-Devirate (bspw. Debian) laufen hier deutlich performanter und haben keine Probleme mit der Anzahl der Querries. Viele Grüße Moritz