Wir betreiben als sozialtherapeutische Institution mit Shopware einen Onlineshop. Der Shop ist ein Unikatenshop, was bedeutet, das jedes Produkt nur einmal gekauft werden kann. Aktuell haben wir 17000 Artikel im Shop. Es sind den ganzen Tag Mitarbeitende dran, Artikel einzugeben.
Unser Webhoster hat nun festgestellt, dass der CPU bei der Eingabe (Speichern des Artikels) eine Auslastung von rund 20% hat und empfindet dies als zu hoch. Was meint ihr dazu? Ist dies zu hoch? Kann ich etwas am Shop optimieren, damit der CPU runter geht? Auch beim Öffnen der Startseite mit der Einkaufswelt geht es teilweise mehrere Sekunden, bis die Grafiken vollständig geladen sind. Wenn ich in die Performance - Cache gehe, lädt es teilweise nicht mal die Cache-Verzeichnis Informationen.
so allgemein schwer zu sagen - um das einordnen zu können, müsste man ja wissen, wie das System insgesamt ausgestattet ist. Gerade bei “günstigeren” Webhosting-Paketen kann es ja auch durchaus sein, dass Shopware da schlicht am Limit der Systemanforderung betrieben wird.
Grundsätzlich kann ich mir schon vorstellen, dass das Speichern von Artikeln etwas mehr Last verursacht, da hängt einiges dran. Ob das aber ein Standard-Problem, ein Hosting-Problem oder auch ein Plugin-Problem ist: Keine Ahnung.
Ich vermute folgendes : Dein Cache-Verzeichnis ist zu groß und beim Artikelspeichern versucht der Cache, die betroffenen Artikeleinträge zu entfernen. Das dauert dann sehr lange und verursacht u.U. viel CPU- und Festplattenlast. Kannst du einmal den Cache komplett leeren und ggf. den entsprechenden Cronjob aktivieren? Das wäre dann ggf. schon eine Abhilfe.
Auffällig bei dir finde ich, dass du auch bei (gecachten) Einkaufswelten so langsame Ladezeiten zu haben scheinst. Das sollte ja relativ flott gehen. Da kannst du mal prüfen, ob Shopware selbst auch langsam ist - oder eben nur das Laden der Bilder (das hängt ja eher an der Umgebung und nicht an Shopware).
Aber wie gesagt: Das mit dem Cache erscheint mir so auf die Schnelle erstmal der beste Verdacht.
hat sich etwa dein Hoster bei dir gemeldet gehabt und sich beschwert das Ihr zu viel CPU braucht?
Ich glaube bei so vielen Artikeln wäre es generell empfehlenswert einen eigenen Server zu haben. 17000 Artikel sind nicht gerade wenige. Ich komme gerade mal auf 5000 Varianten
Überleg mal, bei den meisten Hostern liegen mindestens hundert Kunden auf einen root, und allein Du verursachst schon 20% CPU Auslastung.
Sei froh das der Hoster dir nicht gleich den Saft abdreht. Ist mir vor ca. 10 jahren mal passiert, da hat der Hoster einfach den Stecker gezogen. Bei so vielen Artikeln sollte man schon einen eigenen Server einsetzen.
Aber wie gesagt, kannst froh sein dass dir der Hoster nicht gleich den Vertrag kündigt.
das Speichern eines Artikels kann durchaus im Berich von 15-18% eines vCore liegen, wenn ihr einen virtuellen Server einsetzt. das ist allerdings nur eine extrem kurze Lastspitze und sollte im Frontend nicht zu Problemen führen, solange dort ein mäßiges Besucheraufkommen ist. In der Regel sollte man auch 2 oder mehr vCores haben und dann fangen dieses die Besucher im Frontend auf.
Wenn aber im Backend permanent von verschiedenen Mitarbeitern Artikel gespeichert werden, dann kann das ein Shared Hosting-Paket oder einen kleinen virtuellen Server natürlich auch im Frontend beeinträchtigen. Wenn das 2 Artikel pro Stunde sind, ist das allerdings nicht permanent. Die ~15% Auslastung sind eigentlich relativ unabhängig von der Größe des HTTP-Caches, ich sehe die zumindest bei kleinen und größeren Shops unabhängig von der Größe des httpCache. Kann allerdings die Idee von Daniel nachvollziehen. Die Artikelzahl ist dort nicht so ausschlaggebend, die Last tritt auch nicht bei jeder Bearbeitungsaktion in den Artikelstammdaten auf. Neben der CPU-Leistung ist RAM ein kritischer Faktor, da hilft eine Aufstockung sehr effektiv gegen Swapping auf der Festplatte.
Einen kompletten Server werdet ihr wahrscheinlich nicht benötigen, wenn ihr nicht viele Besucher habt, aber etwas in der Richtung 2-4 vCores, 4GB RAM sollte es schon sein. Das gibt es um die 30 Euro brutto pro Monat. Es gibt auch “Cloud-Systeme” bei denen man die Anzahl der vCores und das RAM flexibel anpassen kann (kostet dann mehr oder weniger). Damit hat man den Vorteil, nicht direkt die Kosten eines eigenen Servers zu haben und kann sich an die benötigten Ressourecen herantasten.
Die HTTP-Cachezeiten im Performance-Modul sind unter Umständen nicht optimal, wenn die einzelnen Produkte nicht dauernd im Frontend aufgerufen werden. Da kann man mit Sicherheit in Kombination mit Cronjobs zum Aufbau/Löschen des HTTP-Caches die Ladezeit im Frontend optimieren. Ob das sinnvoll ist, hängt aber auch von der Artikelstruktur und dem verwendeten Dateisystem ab. Wenn ihr es schafft, einen Artikel in ca. 500-700ms TTFB im Fronten zu laden, könnte man auch argumentieren, dass sich der Management-Aufwand für den Cache nicht lohnt.
Die langen Ladezeiten der EK sind allerdings ein deutlicher Hinweis darauf, dass etwas mit der Leistung des Hostingpaketes nicht stimmt. Wen INteresse daran besteht das auf einem Cloudsystem zu testen, schickt mir eine PM, dann kann ich Euch einen Anbieter empfehlen. Vielleicht meldet sich hier auch schon einer der Marktteilnehmer in diesem Bereich.
Euch allen ein herzliches Danke. Anhand der von euch geposteten Beiträge habe ich bemerkt, dass mit 17000 Artikel doch vielleicht ein eigener Server besser wäre. Ich werde dies nun für uns auswerten und wahrscheinlich einen suchen, der zu uns passt.
Oder man bucht einen dedicated oder managed server bei Hostern. Schreibe aber mal Shopware an, vielleicht können die mal mit großem Artikelbestand die Software testen und optimieren.
Schreibe aber mal Shopware an, vielleicht können die mal mit großem Artikelbestand die Software testen und optimieren
Eigentlich sind 17.000 Produkte kein Problem - hängt natürlich im Detail immer von vielen Faktoren ab (17.000 mit hunderten von Eigenschaften sind dann doch wieder „viel“. Ebenso werden ja manchmal die Varianten nicht eingerechnet - 17.000 mit je 100 Varianten ist auch wieder was anderes ). Das sind aber sicher eher Extremfälle, für die es dann ja bspw. ElasticSearch-Anbindungen gibt.
Gerade zur SW5 haben wir da viel getestet und experiementiert mit verschiedenen Artikelbeständen, darum könnt ihr im Performance-Modul auch beispielsweise bestimmte Filter deaktivieren, die eher ressourcenfressend sind. Das hängt (zum Teil) auch einfach an der Datenbank - Suchen / Filtern kann eine ElasticSearch auch bei Millionen Produkten noch recht gut - das geht auf einem Standard-Hoster mit MySQL sicher nicht.
Um diesem Thema ein Abschluss zu geben, hier noch mein Lösungsweg. Wir haben uns für einen eigenen dezitierten Server entschieden. In unserem Fall sicher der beste Weg, da wir noch weitere Shops (mit nicht sovielen Artikeln) haben. Ich möchte mich bei euch allen bedanken
