Hallo lieber Shopwareianer, wir betreiben einen größeren Shop auf „Profihost“. Dieser soll in naher Zukunft unsere bisherige Shoplösung durch OXID-eSales ablösen. Folgendes Problem macht uns aber starke Kopfschmerzen und vor allen auch Hemmungen, den Schalter umzulegen: Wir haben einige Artikel mit einer überdurchnittlich großer Variantenanzahl (über 2.000 Varianten im Vater). Es gibt eine Kategorie mit ca 100 von solchen Artikeln. 1. Szenario Mehrere Leute gehen gleichzeitig auf diese Kategorie (HttpCache aus) 2. Szenario Wir benutzen ein kleines SEO Tool zum abcrawlen des ganzen Shops zum Ermitteln gewisser Daten (effektiv wird jeder Link 1 mal aufgerufen) Beide Szenarios enden dadrin, dass die Systemlast hoch geht, die Datenbank durch „Copy to disk“ Operationen dicht macht und der Server auf allen Ansichten, die MySQL ansprechen, schmießt über längere Zeit „503 - Temporary Unavaible“ Mit anderen Worten: beide Szenarios (getestet mit und ohne HttpCache) führen dazu, dass unser Server einfach einknickt. Machen wir diese Szenarios aber auf dem Oxid Shop auf dem selben Server, ist alles wunderbar. Wir sind etwas ratlos, und vor allem verzweifelt, da wir begründet Angst haben mit diesem Shop online zu gehen. Es wäre also ein Leichtes, uns mit einem einfachen ProduktCrawler kurzzeitig vom Netz zu nehmen… Version 4.3.4 PE Anzahl Artikel im Shop: ~64.000 Die besagte Kategorie hat Filter-/Artikeleigenschaft-Konfigurationen… Ansonsten eigentlich nichts exoktisches, keine Extra Module, keine Bundle Artikel, keine Zubehörkonfiguration…Dargestellt wird der Shop durch das Responsive Template Tab10 Grest Was könnte man noch unter die Lupe nehmen, oder bestenfalls unternehmen um das in Griff zu kriegen?
Hallo, kannst du uns noch ein paar Informationen über den Server zur Verfügung stellen? Generell sollte der MySQL-Server über genug Speicher verfügen, dass die Daten möglichst komplett in den Speicher geladen werden können. Siehe: (innodb_buffer_pool_size). Ansonsten eine aktuelle PHP Version wie 5.5 und aktivierter OpCache. Das größte Performanceproblem wird jedoch der MySQL-Server bleiben. Hier kannst du mit tools wie MySQL Tuner an der Konfiguration schrauben. Vg, Benjamin :shopware:
Es ist ein Managed Server von Profihost. PMA gibt mir dazu folgende auskunft: Server: Localhost via UNIX socket Software: MySQL Software-Version: 5.5.41-0 - (Debian) Protokoll-Version: 10 Benutzer: unserDbUserEben@localhost Server Zeichensatz: UTF-8 Unicode (utf8) Stichwort „Managed“ bedeutet einerseits, dass wir nicht an MySQL direkt rankommen aufgrund fehlender Rechte, andererseits - um hier einfach mal direkt die Leute von profihost zu zitieren - „Unsere Server sind für Shop Betrieb optimiert“ Heißt erstmal nicht so viel, außer dass man daraus schließen könnte das z.B. die Datenbank zumindest schon mal für den „Produktiv betrieb“ ausgelegt ist von den Einstellungen her
gelöscht
Bzgl. Server Auskunft meinte er wohl eher: Welche Hardware, Apache Webserver ? Welche SQL Version, welche PHP Version etc. Allerdings kann es bei einem Server hunderte Gründe geben, warum dieser keine Leistung bringt. Der häufigste Grund ist hier meistens, dass der Server einfach falsch konfiguriert ist. Allerdings ist es doch ein Managed Server von “Profihost” - helfen die dort denn nicht weiter ? Denn alleine so im Forum ohne auf den Server zu schauen, kann man hier nur raten. Es wird definitiv wohl irgend etwas am Server sein, jedoch wie du schon sagst ist es ein Managed Server. Da wirst du so nicht viel mehr machen können … Und bzgl. “Unsere Server sind für Shop Betrieb optimiert” ist erst einmal eine sehr pauschale Aussage. Jeder Shop - was man ja sehr gut an deinem Beispiel sieht - ist individuell. Und so sollte man natürlich auch entsprechend ein System darauf einstellen 
Hallo, Sehr viel Performance können auch die Filter fressen. Besonders wenn du sehr viele Eigenschaften als Filter anzeigst. Schalte doch einfach mal die Filter für die Kategorie komplett ab. Wenn sich die Performance merklich verbessert, dann einfach weniger Filter anschalten.
super Tip 
Wir nutzen was, was wir nicht nutzen, weil wenn wir es nutzen, bringt es keinen nutzen. Wenn man es braucht muss es laufen und nicht, schalte es ab, es stört nur. Das ist das grösste Hindernis hier das die Performance teilweise echt unterirdisch ist. Sieht man auch am eigene Shopware Shop, schnell ist was anderes. Es läuft zwar stabil aber nicht richtig schnell. Warum liegen teilweise über den ganzen DBs keine Indexe? Würde das extrem beschleunigen. Aber nur meine Meinung.
Hi, > Warum liegen teilweise über den ganzen DBs keine Indexe? das ist nicht zutreffend. Wenn du dir die relevanten Tabellen wie s_articles, s_articles_details, s_articles_categories_ro oder s_articles_prices (und viele andere) ansiehst, wirst du sehr konkrete Indexe finde, die für die verschiedenen Listing-Queries nötig sind und teilweise auch schon Sonderfälle wie bestimmte Filter / Sortierungen berücksichtigen. Es kann natürlich immer sein, dass wir da was übersehen - aber so pauschal kann ich dem erstmal nicht zustimmen. > Aber nur meine Meinung. Die kann man ja im Zweifelsfall durch bspw. einen EXPLAIN belegen, das müsste ja nach deinem neuen Index besser aussehen als vorher. Beste Grüße, Daniel
Also, shopware ist ein sehr schönes Shopsystem, aber leider nicht das performanteste. Ich und auch andere haben die Erfahrung, dass es so ab 30.000 bis 50.000 Artikeln langsam wird. Je nach Server. Bei einem absoluten Hochleistungsserver geht wahrscheinlich etwas mehr. Oder hat da jemand andere Erfahrungen? - würde mich sehr interessieren. [quote]Was könnte man noch unter die Lupe nehmen, oder bestenfalls unternehmen um das in Griff zu kriegen?[/quote] Hashtabellen können das sehr beschleunigen. Und vielleicht wird ja in dem bald erscheinenden Shopware 5 ein bisschen was für die Perfomance getan. (darüber weiß ich aber nichts). Warum willst du denn von Oxid weg? Ist doch auch ein gutes System. (Ohne, dass ich shopware schlecht machen will :thumbup: ) Liebe Grüße Kerstin
Wir haben einige Kunden mit solch vielen Artikeln und hier gibt es keinerlei Performance Einbußen. Es kommt eben sehr viel darauf an, wie gut auch hier der Server schlussendlich konfiguriert ist. Und bei einen Kunden mit 100.000 Artikeln muss man am Server eben hier und da was Schrauben als bei einem Kunden mit 10.000 Artikeln. Dann kommt es letztendlich natürlich auch darauf an, wie die gesamte Seite Seite optimiert ist. Hat diese massig Code Fehler und der Server muss hier erstmal warten, ist es natürlich kein Wunder das die Seite langsam ist/wird.
Das hört sich sehr interessant an. Kannst du mir bitte ein paar Beispiele sagen (gerne auch als PN).
[quote]Warum willst du denn von Oxid weg? Ist doch auch ein gutes System. (Ohne, dass ich shopware schlecht machen will :thumbup: )[/quote] An dieser Entscheidung knabbern wir selbst auch schon etwas: Es hatte damit zutun, dass wir auf das pre 4.2 Design von oxid ein design gebaut haben. Allerdings hatte sich zwischenzeitlich das design so sehr geändert, dass eine Anpassung dahingehend mit Updatefähigkeit ebenso aufwendig wäre, wie z.B. Shopsystem zu wechseln (war im endeffekt nicht wirklich so, aber egal) Ansonsten haben wir in der Tat eine reiche FilterKonfiguration an den Artikeln. [quote]Sehr viel Performance können auch die Filter fressen[/quote] Haben wir global auf Listing Ebene ausgemacht. Nun lädt nach frischen Cache-Leeren die große Kategorie gemessen 5sec, aber der Shop hält der Belastung stand (keine 503er mehr) Ist aber ein unschöner Zustand, so ganz ohne Filter Was ich noch gehört habe ist nämlich dass gerade bei großen Artikelvarianten (>2000 Varianten pro Vaterartikel) Shopware so seine Probleme hat. Ich untersuche dahingehend momentan den Shopware Code, ob bei dem Listing wie auch dem Detail, mehr geladen wird als nur ein Childartikel, oder ob da wirklich die ganzen Varianten nachgeladen werden… auch sehen wir uns gerade seitens Profihost um, ob es ggf am Server liegt. Was uns sehr verunsichert ist leider die Spanne zwischen „Klick auf eine Kategorie und dein Server geht 5 Minuten in Dauer-503-Modus“ bis „Es läuft nen Crawler über die Seite und unsere größten Artikel gehen in <200ms auf“. Und es ist eben alles mal dabei. Nur die 503-Seiten machen uns sehr große Sorgen, weil sowas darf im Live-Betrieb nicht passieren. Wir hoffen wirklich, dass man es nur auf die Filter schieben kann
Hallo, je nach Menge an Artikeln in einer Kategorie, können die Filter natürlich auch einiges an Performance fressen. Hier solltest du einmal testen, ob es merklich schon etwas bringt die Option „Artikelanzahl bei jedem Filterwert anzeigen“ zu deaktivieren. Gerade diese Funktion, also die Berechnung der Menge an Artikeln pro filter (wird in Klammern dahinter angezeigt) frisst eine ganze Menge Performance. Da sie aber für die Nutzung der Filter nicht unbedingt relevant ist, solltest du diese mal testweise abschalten. Die Funktion findest du im Performance-Modul (Einstellungen > Caches/Performance) im Reiter Einstellungen > Filter. Grüße Moritz
[quote=“japanwelt”] Ist aber ein unschöner Zustand, so ganz ohne Filter Was ich noch gehört habe ist nämlich dass gerade bei großen Artikelvarianten (>2000 Varianten pro Vaterartikel) Shopware so seine Probleme hat. Ich untersuche dahingehend momentan den Shopware Code, ob bei dem Listing wie auch dem Detail, mehr geladen wird als nur ein Childartikel, oder ob da wirklich die ganzen Varianten nachgeladen werden… [/quote] Im Listing wird z.B. der günstigste Preis aller Varianten ermittelt um diesen anzuzeigen, habe das aber noch nicht genauer untersucht. Der Aufruf müsste irgendwo in der sArticles liegen. Wenn es tatsächlich über 2000 Varianten pro Artikel sind könnte ich mir schon vorstellen, dass dieser Vorgang lange dauert.
[quote]Hashtabellen können das sehr beschleunigen.[/quote] ich bin mir nicht sicher, ob das angekommen ist. Könnte aber wirklich eine Lösung sein. Wenn du schon mal beim Programmieren bist. Liebe Grüße Kerstin
In diesem Zusammenhang gleich mal 2 Modul(an)fragen 1. Performance Filter Hab da gerade nen Blick in den Store geworden, leider ohne Erfolg… 2. Listing - Varianten Modul beide würden vom Konzept der „Daten-Denormalisierung“ profitieren, also das auslagern teurer Werte in die Spalten des Artikels. So kann man (ggf auch via Attribute) Werte wie Artikel Je Filter bzw. günstigster Preis auf eine extra ebene Ziehen, die aber nicht jedes mal berechnet werden muss. Diese Werte müssten lediglich beim Bearbeiten des Datenbestands aufbearbeitet werden. Dies könnte man entweder elegant auf Ebene von Doctrine oder sogar durch Trigger in MySQL umsetzen… Solche Verfahren bringen immer das Risiko von Inkosistenzen mit ins Haus, sparen aber hier erhebliche Kosten des Servers und würden das Problem beheben Hat jemand in diese (oder Ähnliche) Richtung schon etwas entwickelt? Würde Interesse bestehen, im Falle der Nichtexistenz, dass ein solches Modul entwickelt wird? lg japanwelt
[quote]Hat jemand in diese (oder Ähnliche) Richtung schon etwas entwickelt? [/quote] ja