ich hoffe ich bin in dieser Kategorie richtig. Falls nicht, möge man mir bitte verzeihen. ;-)
Ich stehe im Moment vor der Frage, ob für unser vorhaben eine ein Server Lösung ausreichend ist oder ob wir besser auf eine Zwei Server Lösung bauen sollten.
Die Zwei Server Lösung würde bedeuten, dass wir einen relativ „schmalen“ Webserver hätten dagegen aber einen angemessenen DB Server.
Folgendes ist gegeben:
Produkte ca. 3 Millionen, wovon aber „nur“ rund 20.000 mit Eigenschaften versehen sind oder in Varianten unterteilt sind.
4055 Kategorien bis maximal Ebene 4
Im Moment rd. 16.000 Visits auf dem Shop
Falls noch Infos benötigt werden, könnte ich die besorgen.
also bei 3.000.000 Produkten wirst du schon Elastic Search brauchen. Das schafft Shopware im Standard nicht und da stößt auch so jede MySQL-Lösung an ihre Grenzen. Darüber hinaus sind 4.000 Kategorien auch eine ganze Menge. Das wird beides mit einem normalen Server relativ schwer zu realisieren sein. Mit Elastic Search würde ich sagen - möglich - ohne würde ich das ganze erstmal testen. Denke aber da wirst du definitiv Performance Probleme bekommen, unabhängig von deinem Server-Setup.
Hier wirst du wahrscheinlich testen müssen - aber um mal meine Erfahrungen zu teilen: wir haben knapp 8.000 Kategorien bei ca. 800.000 Artikel-zu-Kategorie-Verknüpfungen. Reine Lese-Vorgänge sind zwar relativ flott - aber Schreibvorgänge brauchen eine gefühlte Ewigkeit (wahrscheinlich auf Grund der vielen Indexe). Wir sind nun gezwungen über mehrere Server nachzudenken. Aber: ein „standard“ Server für 80,- Euro im Monat wird für dich definitiv nicht ausreichen.
Ich würde mal behaupten allein Cache leeren und dann stück für stück erstellen ist sehr Serverlastik. Ich merke es schon bei 50.000 Produkten. Auch die SSD sollte für Cache und mysql schnell und groß genug sein!
Bestenfalls Cache nie per hand und komplett löschen
Moritz, weißt du ob Elastic Search auch genutzt wird, wenn die Filter im Artikellisting bedient werden?
danke erst mal für eure Antworten. Also Elastic Search kommt für uns im Moment anhand der Kosten für eine gescheite Lösung, über mehrere Data Nodes, nicht in Frage.
@derkosta, das Caching ist ja an sich auch nicht dazu da um ständig gelöscht zu werden. Und unsere Testmaschine, geht jetzt auch bei Suchanfragen nicht unnötig in die Knie, eigentlich dümpelt die vor sich hin.
wir haben knapp 8.000 Kategorien bei ca. 800.000 Artikel-zu-Kategorie-Verknüpfungen. Reine Lese-Vorgänge sind zwar relativ flott - aber Schreibvorgänge brauchen eine gefühlte Ewigkeit (wahrscheinlich auf Grund der vielen Indexe).
Kann auch an der Cache-Invalidierung liegen, wenn ihr den SW-Reverse-Proxy benutzt. Auch der CategoryDenormalizer kann da rein spielen. Hängt natürlich immer davon ab, wo die Schreibvorgänge diese Verlangsamung verursachen.
Also Elastic Search kommt für uns im Moment anhand der Kosten für eine gescheite Lösung, über mehrere Data Nodes, nicht in Frage.
Bei 3 Millionen Produkten (wenn wir da keine unterschiedlichen Definitionen haben) würde ich aber auch dringend zu ElasticSearch oder einer ähnlichen Lösung raten. Ansonsten wird dir mit MySQL das Produktlisting stark einbrechen. Das ist mMn aber auch nicht nur bei Shopware so - das ist einfach schon eine sehr große Datenmenge, um darüber noch in MySQL Preise / Hersteller / Eigenschaften etc filtern / sortieren zu können.
Kann auch an der Cache-Invalidierung liegen, wenn ihr den SW-Reverse-Proxy benutzt.
Das muss ich mal testen… Danke für den Tipp!
Auch der CategoryDenormalizer kann da rein spielen. Hängt natürlich immer davon ab, wo die Schreibvorgänge diese Verlangsamung verursachen.
Das meinte ich übrigens: wir haben ca. 800.000 Einträge in der _ro Tabelle.
Hast du zufällig sonst noch Ideen oder TIpps, was ich mir mal anschauen oder testen könnte?! Aktuell dauert es 4 Sekunden (!), um einen Artikel einer Kategorie zuweisen zu können.
Ui, das ist sicher nicht das einfachste Geschäftsmodell. Ich kenne ähnliche Projekte in denen auch 1 Mio. Artikel im Webserver (ich sage mal bewusst nicht Shop) vorhanden sind und bei erstmaligen Bestellungen nach und nach in das ERP einfliessen. Sonst würde das lokal den Rahmen sprengen.
Derlei Fälle sollte man ganz konkret betriebswirtschaftlich ausarbeiten und betrachten.
Da am Herzstück der Schnittstelle zwischen Kunden und Unternehmen zu sparen oder nicht genau genug zu planen ist leider oft genug in der Praxis zu erleben.
@pemmler, danke für deine Antwort. Es geht gar nicht umbedingt ums sparen, sondern viel mehr um die Wirtschaftlichkeit. Es macht ja keinen Sinn, für EUR 1.000+ Server zu unterhalten, was wir aktuell haben und diese gar nicht benötigt werden. Und ES kommt für uns nicht in Frage, weil das halt auch wieder jemand monitoren muss und wir jemanden im Haus brauchen, der davon Ahnung hat und das haben wir aktuell nicht.
Wir haben jetzt einen recht großen dedizierten Server gemietet, und mysql soweit optimiert (keine Queryoptimierung im Moment), das der Shop relativ gut performt trotz der doch recht großen Datenmenge.
danke für deine Antwort. Das tausend Flocken zu viel sind, für die paar User, weiß ich. Deshalb haben wir ja die Resourcen auf ein akzeptables minimum runtergefahren. ;-)
Also Elastic Search kommt für uns im Moment anhand der Kosten für eine gescheite Lösung, über mehrere Data Nodes, nicht in Frage.
Darf ich fragen, was man Dir über die Kosten für ElasticSearch erzählt hat? Bei den meisten Shopware-Hosting-Partnern wird ElasticSearch kostenlos vorinstalliert sein.
