Systemanforderungen für kleinen Magento-Shop

[sia]

Hi Leute,

Ein Kunde hat einen Magento-Shop mit ca. 200 eigenen Produkten und ca. 30k Seitenimpressionen im Monat, davon 200 Bestellungen, bei einer Agentur gehostet, möchte diesen aber jetzt "zu mir" umziehen.

Da ich bei Magento keinerlei Erfahrung habe und auf den derzeitigen Server außer mit SFTP keinen Zugriff habe (zwecks Benchmarking), würde ich gerne wissen, was ich dafür an Rechenleistung benötige.

Reicht da das Netcup-Hosting 8000 mit 1024M PHP Memory Limit und 30 Leuten auf einem Server? Oder benötige ich zwingend einen dedizierten Server?

Wenn das Ding gut läuft, wird das Hosting selbstverständlich redundant und "kraftvoller" aufgebaut werden, das jetzige Ziel ist, den Shop schneller und stabiler zu machen als bei der Agentur. Jede zehnte Bestellung "hängt" nämlich aufgrund von unzureichenden Systemressourcen (zumindest nehme ich das an, dank Timeouts).

EDIT: Magentos Dokumentation sagt "up to 2GB of RAM", aber ist das auf einem einzelnen PHP-Skript oder für das gesamte System?

EDIT2: Habe mal phpinfo() ausgeführt und aktuelles memory_limit ist 256M… Ist wohl ein 1&1-Reseller-Server oder so?

 

[theSplit]

@phre4k: Die 2 GB RAM beziehen sich aber auf Upgrades:

Aus deiner verlinkten Doku:

Memory requirement

Upgrading the Magento applications and extensions you obtain from Magento Marketplaces and other sources can require up to 2GB of RAM. If you are using a system with less than 2GB of RAM, we recommend you create a swap file; otherwise, your upgrade might fail.

Das ist aber laut Beschreibung vermutlich nicht die reale Nutzung des Shopsystems unter Last.

Gibt es dazu keine Benchmarks?

Vielleicht kannst du das mal folgendermaßen testen:
- Shopsystem einrichten
- Zufällig (über ein Skript) xxx (300+) Artikel erstellen lassen, mit Inhalten (Bilder und Texten) und alle anderen Daten, Zufallsdaten, die die Limits ausnutzen
- dann den Speicherbedarf messen mittels Monitoring
- und dann alle Artikel und (Unter)Seiten, mehrere, anfragen generieren (Python, CURL automatisiert? aus Textdatei füttern?)

so sollte man eigentlich sehen wann wie und wo ausgelagert wird, evtl. wird viel oder wenig gecached wird oder gar nicht? - Jedenfalls sollte man so ein wenig Load simulieren können, und das dann hochrechnen.

Das PHP Memory Limit ist aber, so wie ich es verstehe nur für die Ausführung eines PHP Skripts und du wirst vermutlich kein PHP-Skript haben, das 256 MB an Daten bearbeitet? Eher ein paar MB für Paging, Artikelhighlight/Übersichten und oder ähnliches zu realisieren, aber da auch nur bestimmte X Artikeleinträge gleichzeitig aus der Datenbank in einer Kategorie zu ziehen und anzuzeigen. Nicht 200 Artikel in einer Liste.

Das ursprüngliche Problem scheint ja eher die Performance des Shopsystems zu sein.

"Kommt aber auch darauf an, was du für einen Webserver im Einsatz hast und auch welche (aktuellere) PHP Version, falls es merkliche Unterschiede gibt... - bei PHP wird öfter gesagt, neuere Versionen sind weniger Speicherhungrig als ältere und oder performen besser." - irgendwie so ist das Mantra dazu

Aber vielleicht hilft dir auch schon der Guide, lass sich zumindest ganz gut... - habe ich aber nicht getestet.

--- [2018-01-25 20:57 CET] Automatisch zusammengeführter Beitrag ---

Nachtrag: Testsystem Shop und Testsystem "Traffic Generator" nicht auf dem gleichen System!

Ein Testserver wäre ideal, de facto ein zweiter Rechner....

Und ich würde das Memory Limit runterschrauben, auf 16 MB... das ist nicht nur ein Schutz, aber wenn es irgendwo knallt, bekommst du vielleicht die Info welcher Request einen Fehler verursacht hat.
Wenn du 100 parallele Anfragen a 16 MB hast, sind das schon 1600 MB RAM - das könnte schon ein Großteil sein, daher, die Skripte sollte optimiert sein nicht so viel MB RAM zu verbraten, bei der Laufzeit.

Allerdings müsste ich mich da auch noch einmal über das Memory Limit schlaulesen, ist nicht so das ich mich jeden Tag damit beschäftige und einschätzen kann ob ein mögliches Caching auch unter das Limit fällt...

Ansonsten, der Load Generator sollte schon helfen aus dem Guide. Damit kannst du zumindest mal überblicken wie viel oder wenig Traffic ausmacht.

 

[sia]

Gibt es dazu keine Benchmarks?

Keine gefunden.

Vielleicht kannst du das mal folgendermaßen testen:
- Shopsystem einrichten
- Zufällig (über ein Skript) xxx (300+) Artikel erstellen lassen, mit Inhalten (Bilder und Texten) und alle anderen Daten, Zufallsdaten, die die Limits ausnutzen
- dann den Speicherbedarf messen mittels Monitoring
- und dann alle Artikel und (Unter)Seiten, mehrere, anfragen generieren (Python, CURL automatisiert? aus Textdatei füttern?)

Gute Idee, mach' ich. Muss ich eben für 1 Monat einen Testserver bestellen.

Das PHP Memory Limit ist aber, so wie ich es verstehe nur für die Ausführung eines PHP Skripts und du wirst vermutlich kein PHP-Skript haben, das 256 MB an Daten bearbeitet?

Och, Webshops und CMS sind da kreativ, was Speicherauslastung angeht. Im Allgemeinen hast du da recht, aber bei Updates und Reports dürfte ein memory_limit von <256MiB schon schnell limitieren.

Das ursprüngliche Problem scheint ja eher die Performance des Shopsystems zu sein.

Korrekt, und dass das derzeit eine sauteure Agentur hostet. phpsysinfo sagt mir, dass die einen E5-1650v3 mit 12x3,5GHz und 128GiB RAM haben. Da da 16 IPs drauf sind und das nur eine 1GBit/s-Anbindung ist, denke ich nicht, dass da mehr als 16 Kunden drauf sind. Macht ca. 3GHz/Kunde.

Aber vielleicht hilft dir auch schon der Guide, lass sich zumindest ganz gut... - habe ich aber nicht getestet.

Der Link war kaputt, hab mal korrigiert. Hilft mir leider nicht viel "im Voraus", aber vielleicht für's Benchmarking.

Nachtrag: Testsystem Shop und Testsystem "Traffic Generator" nicht auf dem gleichen System!

Ach was :'D

---

Habe über eine Stackoverflow-Frage bei einem Magento-Hoster noch das hier gefunden:

https://www.sonassi.com/help/reference/cpu-sizing

Concurrency

• A standard Magento demo store is capable of delivering roughly 230 uniques per GHz, per hour.
• A typical web store, with admin user activity, development activity, product addition/deletion can see this degrade by around 100%, to 115 uniques per GHz, per hour.
• A store with a poorly built/heavy template can further reduce the figure by another 100-200%, to 50 uniques per GHz, per hour.

→ das sagt mir, dass bei ca. 1kPI/d (=max 200PI/h) eigentlich 1GHz ausreichen sollte. Das haben ja selbst die billigsten vServer.

https://www.sonassi.com/help/reference/ram-sizing

→ das hilft mir wiederum gar nicht, aber 2GB RAM sollten es wohl mindestens sein. Habe bei netcup mal angefragt, wie viel RAM man beim Webhosting 8000 zur Verfügung hat.

 

[drfuture]

Ich würde um ehrlich zu sein einfach bei netcup nachfragen und vielleicht noch bei all-inkl.com - die dürften durchaus Erfahrung mit solchen Fragen haben und hoffentlich auch eine Antwort haben.

die 256mb sind bei prozessen die die Bilder aufbauen im Shop oder vielleicht sogar dynamisch irgendwelche Vorschauen generrieren im Shop schnell weg.

 

[Shodan]

Jede zehnte Bestellung "hängt" nämlich aufgrund von unzureichenden Systemressourcen (zumindest nehme ich das an, dank Timeouts).

Wolle Katze kaufen? Ist im Sack. Keine Sorge ist gute Katze. Richtig brav nur etwas hungrig.

Die brauchen keinen alternativen Hoster, sondern einen Geisterjäger (aka technischen Analysten) der Logfiles auswerten kann und ihnen sagt, warum die Anwendung kaputt ist. Der macht dann aber keine Annahmen, sondern legt einen Bericht vor in dem drin steht, woran es liegt. Kann natürlich fehlender RAM sein, aber da auf verdacht mal auf einen anderen Server umzuziehen klingt jetzt nicht nach einem wirklich guten Plan.
Wahrscheinlich ist die Datenbank über Jahre auf 10GB gewachsen, weil keiner die Logfiles pruned und nun arbeitet sich die datenbankintensive order halt gelegentlich tot. Das sieht dann auch nach Ram aus, lässt sich aber per Webinterface in Magento lösen. Sogar dauerhaft, man muss nur einstellen, wie viele Tage sich das Ding die Logs merken soll. Frag nen Manager nach den Anforderungen Sales-Informationen aufzubewahren, wenn der Ahnung hat sagt er 5 Jahre. Ist halt die falsche Frage.

Reicht da das Netcup-Hosting 8000 mit 1024M PHP Memory Limit und 30 Leuten auf einem Server? Oder benötige ich zwingend einen dedizierten Server?

Reicht, wenn die Leute sich in einer Schlange anstellen und wie im Supermarkt brav nach einander einkaufen.
Wenn eine Seite mit 1024 MB PHP Memory pro Prozess wirbt, zu dem Preis, und dir nicht sagt, wie viele Prozesse du bekommst, bekommst du wahrscheinlich exakt einen.
Das kann reichen, laut den Impressions hat sie ja, nehmen wir an die Kunden besuchen die Seite nur werktags zwischen 10 und 18 Uhr, nur alle 10 Sekunden eine Impression.
Wenn du aber sagst, dass da auch mal 5 bis 10 Leute "gleichzeitig" einen Request vom PHP beantwortet haben wollen:
5 Views * 200 Produkte = 1000 --> 8GB laut Sonassi via Stackoverflow.


Was läuft denn auf der aktuellen Maschine überhaupt? Worst Case? Apache prefork + mod_php ohne caching. In dem Fall brauchst du viele Childs um den statischen Content auszuliefern und jedes Child kann mit dem vollen Speicherbedarf von PHP laufen. In dem Fall brauchst du einen Cache, der die 30 Bilder, 5 JS und 5 CSS Dateien ausliefert, statt das den (preforked mod_PHP)-Apache machen zu lassen, nginx + php-fpm sind nicht so ein Speicherschwein und können auf den Cache evtl auch verzichten.

Damit das System am Ende gut läuft musst du wissen
wie viel RAM du jedem PHP Child Process geben musst.
wie viele PHP Child Prozesse du parallel benötigst.
wie viel RAM du der Datenbank geben musst.
wie du statischen Content performant auslieferst
ob es Caches gibt die auch RAM wollen z.B. memcached, redis, varnish

Keine Ahnung?

Ziel ist, den Shop schneller und stabiler zu machen

Erklär mir mal, wie du das genau machen willst.

Bevor du so ein System übernimmst, musst du wissen, woraus es besteht, evaluieren, was du ändern willst und mit dem Kunden klären, was er zahlt.
Ich persönlich habe Magento aber nie ausprobiert, und kann nur auf Basis von Höhrensagen argumentieren. Meine Worte musst also mit Salz genießen. Vielleicht taucht hier ja noch jemand auf, der so einen Shop erfolgreich, stabil und performant betreibt.

Frag mal bei "So 'n Assi Hosting" (Seltsamer Name) nach.
Die haben ein Webformular, wo du die Daten, die du uns gegeben hast einfach eingeben kannst.

8 cores @3.5 GHz
16GB Memory RAM
Das ist deren kleinstes Angebot!
Könnte Abzocke sein.. oder ein Hinweis, dass 1GB PHP Speicher nicht ganz das ist, was Magento braucht.
Magento ist eine Edelnutte. Die will Speicher, die will jede Menge Partnersysteme, die will kostenpflichtige Extensions.
Und richtig sexy wird sie erst in der Enterprise Edition ab > 22.000 im Jahr. (Ohne Hosting und Entwickler, nur die Lizenz).

16GB Ram zu kaufen ist nicht das Problem. Das System so zu konfigurieren, dass es "schneller und stabiler" ist, ist das Problem.
Die wollen dafür mehrere hundert im Monat (gut "stabil" heißt da halt SLA). Und die empfehlen ihren Kunden eine Entwickler-Agentur, das ist da nicht mit drin.

 

[sia]

Die brauchen keinen alternativen Hoster, sondern einen Geisterjäger (aka technischen Analysten) der Logfiles auswerten kann und ihnen sagt, warum die Anwendung kaputt ist.

Das traue ich mir zu. Allerdings habe ich auf die Server-Logs leider keinen Zugriff, da nur SFTP und kein SSH, wie im Startbeitrag erwähnt.

Der macht dann aber keine Annahmen, sondern legt einen Bericht vor in dem drin steht, woran es liegt. Kann natürlich fehlender RAM sein, aber da auf verdacht mal auf einen anderen Server umzuziehen klingt jetzt nicht nach einem wirklich guten Plan.

Der Grund, umzuziehen, ist eher, herauszufinden, woran es liegt, und überhaupt mal Zugriff auf Hosting und DNS zu bekommen. Bisher läuft das durch die Agentur als "Proxy". Server "aufstocken" kann man dann ja immer noch.

Wahrscheinlich ist die Datenbank über Jahre auf 10GB gewachsen, weil keiner die Logfiles pruned und nun arbeitet sich die datenbankintensive order halt gelegentlich tot.

Nein, Datenbank-Dump ist gerade mal ca. 190MiB groß.

Reicht, wenn die Leute sich in einer Schlange anstellen und wie im Supermarkt brav nach einander einkaufen.

Leider ist es derzeit noch so.

Wenn eine Seite mit 1024 MB PHP Memory pro Prozess wirbt, zu dem Preis, und dir nicht sagt, wie viele Prozesse du bekommst, bekommst du wahrscheinlich exakt einen.

Hatte ich bereits vermutet und auch das Netcup-Forum war da bisher nicht wirklich hilfreich. Die haben mir erst mal – wie du – erklärt, was ein PHP Memory Limit ist.

Wenn du aber sagst, dass da auch mal 5 bis 10 Leute "gleichzeitig" einen Request vom PHP beantwortet haben wollen:
5 Views * 200 Produkte = 1000 --> 8GB laut Sonassi via Stackoverflow.

Joah, finde ich schon krass viel. Wobei ich da eher glaube, dass es um Magentos Store Views geht als um die Page Impressions. Davon haben wir soweit ich weiß 3.

Was läuft denn auf der aktuellen Maschine überhaupt?

Gute Frage. Hier mal ein Auszug aus phpsysinfo: https://imgur.com/F2ZQDND → das ist aber wie gesagt der Server der ganzen Agentur und nicht nur des einen Kunden. Dass der bei 1&1 liegt, weiß ich auch. Jetzt weiß ich aber immer noch nicht, ob die Agentur da einen Reseller-Webspace hat oder einen Managed Server oder den Server selbst administriert… da kann ich leider nur raten. Und dieses Ratespielchen wollen meine Auftraggeber eben beenden.

nginx + php-fpm sind nicht so ein Speicherschwein und können auf den Cache evtl auch verzichten.

Hatte vor, das einzusetzen.

Erklär mir mal, wie du das genau machen willst.

System auf neuen Server umziehen, die uralte Magento-Installation auf die aktuelle 1. aktualisieren und die entstehenden Fehler dann iterativ fixen, bis es läuft. Dafür sind ca. 75 Stunden angesetzt und ich werde mir einen PHP-Entwickler mit ins Boot holen. Das kann ich aber erst tun, wenn ich Zugriff auf das Webhosting habe.

EDIT: Sehe gerade, dass ich vielleicht lieber noch die Version 1.9 statt 2.2 einsetzen will, da es keinen "clear upgrade path" zu 2.2 gibt, was auch immer das heißt. Bisher ist es aber noch nicht mal klar, ob nach dem Umzug nicht sogar auf ein anderes System migriert wird. WooCommerce und PrestaShop stehen hier im Raum, die Tendenz ist allerdings, bei Magento zu bleiben.

Bevor du so ein System übernimmst, musst du wissen, woraus es besteht, evaluieren, was du ändern willst und mit dem Kunden klären, was er zahlt.

Schon erledigt. Dateibackup und DB-Dump sind gezogen, vielleicht setze ich auch einfach mal lokal eine VM auf.

 

[theSplit]

@phre4k: Ich weiß nicht ob es das für Magento gibt - aber in Wordpress gibt es eine Möglichkeit Blog Artikel "statisch" ausliefern zu lassen und zu statische HTML Seiten zu generieren, anstelle die jedesmal von Null auf zu erzeugen.

Wenn die Preise sich nur selten ändern, oder gar "fest stehen"... wäre es vielleicht auch ein Mittel dazu, die Anforderungen an die DB/PHP auszulagern und eben statisch auszuliefern. Das heißt man generiert einmal alle Seiten, bis auf die Kernkomponenten die sich regelmäßig ändern - also zum Beispiel Landing pages, Startseite mit Aktionen/Rabatten/Sonderaktionen, was noch etwas dynamik erfordert.

Und wegen dem Memory Limit, ich würde das erst mal heruntersetzen beim Testen, wenn es irgendwo knallt oder hängt, sollte das beim "Benchmarking" evtl. sichtbar sein und herauskommen, würde ich hoffen, aber das müsstest du testen.
Oder du mußt für die PHP Dateien einzelne Limits setzen, damit du steuern kannst, wieviel MB RAM ein PHP Skript verwende kann, was dann aber die generellen Einstellung überschreibt, so weit ich darüber Bescheid weiß.

Nur wie Shodan auch sagt, wenn du 10 Zugriffe a 256 MB hast, sind das 2560 MB RAM, genau das würde die ganze Seite unbrauchbar machen. Daher gilt es, "weniger ist mehr" und "nicht wir stellen 256 MB ein und vergessen es".
Das Limit ist auch ein Schutz, eben damit ein Prozess/Skript nicht allen Speicher des Servers auffrisst und die Seite unbenutzbar macht.


Just my 2 cent.

 

[sia]

@phre4k: Ich weiß nicht ob es das für Magento gibt - aber in Wordpress gibt es eine Möglichkeit Blog Artikel "statisch" ausliefern zu lassen und zu statische HTML Seiten zu generieren, anstelle die jedesmal von Null auf zu erzeugen.

Das erwähnte Shodan schon, PHP opcode caching ist zudem unabhängig von der Anwendung. Würde in dem Falle nginx+php-fpm+Default-PHP-opcache nutzen, das sollte erst mal reichen.

Habe mir jetzt mal ne Shell hochgeladen (einfach fsockopen/proc_open) und für ulimits gecheckt (keine), /proc/[pid]/limits der PHP-Prozesse liefert mir auch keine Limits, leider bin ich mit meinem User aber im chroot und kann daher die php-/Apache-Config nicht einsehen. Ist aber tatsächlich mod_php und kein fpm oder sonstiges.

Stehe gerade ein wenig auf dem Schlauch – wie finde ich außer mit einer forkbomb heraus, wo hier die Limits liegen? Privilege escalation finde ich bedenklich, da a) unhöflich auf fremden Systemen und b) vermutlich sogar illegal.

 

[theSplit]

Mal ne Frage, wenn man seriös arbeitet, ist man als Agentur nicht dazu "mehr oder minder" verpflichtet, einige Eckdaten des Projekts "sorgfältig zu übergeben?" (außer eigene Arbeit, speziell "Source code" ?)

Klar, doof wenn ein Kunde weg will - aber man sollte ja keine Steine in den Weg legen... oder man verscherzt es sich mit dem Kunden und dem, der die Seite übernimmt, oder?

Die Frage daher, vielleicht kann man auch mal nett anfragen bei der Agentur, anstatt das "Live-System" zu penetrieren.

 

[sia]

Mal ne Frage, wenn man seriös arbeitet, ist man als Agentur nicht dazu "mehr oder minder" verpflichtet, einige Eckdaten des Projekts "sorgfältig zu übergeben?" (außer eigene Arbeit, speziell "Source code" ?)

Hahahaha, ja. Versuch' das mal durchzusetzen, wenn die Agentur sämtliche Hebel in der Hand hält.

Klar, doof wenn ein Kunde weg will - aber man sollte ja keine Steine in den Weg legen... oder man verscherzt es sich mit dem Kunden und dem, der die Seite übernimmt, oder?

Verscherzt haben die es sich definitiv jetzt schon.

Die Frage daher, vielleicht kann man auch mal nett anfragen bei der Agentur, anstatt das "Live-System" zu penetrieren.

Wurde schon vor ner Woche getan :'D

 

[theSplit]

@phre4k: Da weiß man ja Bescheid...., wenn das mal die Runde macht.

Edit: Wenn ich der Kunde wäre, würde ich mal eine Rezession über den Dienstleister, auf Portalen schreiben, wo die werben... und das die Agentur sich dagegen sträubt Daten zu übergeben und nicht mit anderen Dienstleistern zu kooperieren.

Man muß ja nichts verunglimpfen, aber aufklären. So etwas gehört sich nicht. *Meinung*

Und leider sind mache Leute was dagegen klagen betrifft, ziemlich dünnhäutig, aber der Kunde hat vermutlich Geld für ein Produkt bezahlt und die Entwicklung, Einbindung von Daten und Miete für das Hosting, ist auch die Frage, gehört es ihm oder der Agentur?

Und was gehört dazu, ne Zahl zu nennen? - Ist ja nicht so, das man Auskunftspflicht hat, aber das ist trotzdem ziemlich "arrogant". Und so jemand hält sich nicht am Markt? Außer man verkauft "Gold- und Diamantgruben"? Nein.

 

[Shodan]

auch das Netcup-Forum war da bisher nicht wirklich hilfreich. Die haben mir erst mal – wie du – erklärt, was ein PHP Memory Limit ist.

Hey sorry, aber du weißt doch wie es hier läuft Du hast fast keine technische Details geliefert, also fangen wir bei den Basics an. Best practice und so, auch wenn du hier ja kein Unbekannter bist.

OT:

Spoiler

Wenn man mal einem Server beim out-of-memory crashen zugesehen hat, weil der mit (Serverlimit * Speicherbedarf) > RAM konfiguriert war, obwohl er von Profis eingerichtet wurde, glaubt man halt an gar nichts mehr. Wer im Netz sucht findet viele "Tuning Tutorials", die genau das sogar empfehlen: durchschnittlichen Speicherbedarf von httpd messen, dann den verfügbaren RAM durch diese Zahl teilen und die max childs auf diesen Wert setzen. Ich habe, aus offensichtlichen Gründen, mal eines verlinkt, das nicht richtig schlecht, sondern nur etwas fragwürdig ist. Vielleicht habe ich hier auch einen Denkfehler. Wenn mir jemand detailliert erklären kann, warum dieses "auf Kante nähen" sinnvoll, statt super risky sein soll, wäre ich sehr dankbar. Mein Verständnis ist: wenn root seinem Linux sagt "gib dem Webserver solange Speicher bis für sshd keiner mehr da ist", dann macht es unter Last auch genau das. Warum wird da mit dem durchschnittlichen Speicherbedarf gerechnet, statt mit dem Höchstwerten? Worst Case Szenario einfach ignorieren?

Das traue ich mir zu. Allerdings habe ich auf die Server-Logs leider keinen Zugriff, da nur SFTP und kein SSH, wie im Startbeitrag erwähnt.

Katze im Sack Nur dass du weißt, dass es eine Katze ist, dass sie lebt, und dass sie super wütend ist.
Wenn du dir das zutraust: viel Spaß. Wir können dir nur die passende Schutzkleidung empfehlen.

Joah, finde ich schon krass viel. Wobei ich da eher glaube, dass es um Magentos Store Views geht als um die Page Impressions. Davon haben wir soweit ich weiß 3.

Da kann ich mir wohl ein berechtigtes "wenn man keine Ahnung hat einfach mal..." einsammeln Seltsam, dass die Anzahl der Requests in der Rechnung nicht vorkommen.
Bleibe aber dabei: der Profi-Hoster, den du schon rausgesucht hast, fängt bei 16GB an. Vielleicht läuft es auch mit 8. Ist der Preisunterschied signifikant genug, dass es sich nicht lohnt etwas höher zu dimensionieren?
Ich kann nur vom Höhrensagen erzählen:

Spoiler

Ich hatte einen Kollegen, der ein Magento-Projekt betreut hat. Der hat auch ordentlich Hardware geordert, an vielen Stell-Schrauben gedreht, Konfigurationen optimiert, sich intensiv mit dem Datenbankindexes beschäftigt, Extensions ausprobiert, die Caches studiert und dann immer noch drüber geflucht. Wenn ich intensiv drüber nachdenke war das Hauptproblem damals aber, dass die Kundin gerne mal mit neuen Ideen (Anforderungen) um die Ecke kam, die Magento so nicht out of the Box konnte und mit Gegenvorschlägen, basierend auf dem was es konnte, nicht richtig zufrieden war. Ist aber lange her und nur Kaffeklatsch. Ich war froh nicht beteiligt zu sein und habe kein gutes Bild von der Software bekommen. Das Projekt ist irgendwann an ausufernden Kosten gestorben und wurde mit "as good as it gets" beendet. Magento ist eine ziemlich komplexe Software, Features nachzurüsten ist nicht trivial

da es keinen "clear upgrade path" zu 2.2 gibt, was auch immer das heißt.

Heißt, dass das "Major Version update" nicht abwärtskompatibel ist. Finde ich nicht überraschend, eher normal.
Hat das System Maßanfertigungen drin? Die könnten schon bei einem Minor-Version Update auseinanderfallen.
Lass mich raten: Doku gibt es auch nicht und auf dem Server liegen auch nur die nakten Dateien ohne GIT History?
Katze im Sack... Vielleicht sind die 10% ausfallenden Orders gar kein Problem des Speichers, sondern lassen sich auf irgend ein reingehacktes Feature zurückführen. Versuch mal die exakte Version des eingesetzten Magentos in clean aufzutreiben und diff die gegen den Stand vom Server um herauszufinden, ob da was manipuliert wurde.

@phre4k: Man muß ja nichts verunglimpfen, aber aufklären. So etwas gehört sich nicht. *Meinung*

Da stimme ich dir zu. Und hoffe insgeheim, dass es nicht von uns ist und die Kollegen meinen Ruf durch Assoziation zerstören :'D

Würde in dem Falle nginx+php-fpm+Default-PHP-opcache nutzen, das sollte erst mal reichen.

Stimme da grundsätzlich zu. Erst mal ne sinnvolle Basisinstallation machen und die Performance messen, bevor man noch zwölf dutzend Layer drumrumbaut in der Hoffnung, dass die mehr bringen wie schaden.

Magento hat einen ganzen Stapel Caches integriert. Die Software ist, vom Design her, wohl schon nicht schlecht. Magentos dateibasierende Caches durch Redis zu ersetzen und den nginx internen fcgi cache explizit im RAM zu halten ist eine Überlegung wert. Wobei Linux dir, sofern du genug RAM hast, die dateibasierenden Caches sowieso im RAM halten sollte. Ob das also wirklich was bringt, muss man messen.

nginx+fpm nimmt dir das Problem mit dem Ausliefern des statischen Contents und dem ServerLimit ab, weil du den Speicher für PHP individuell konfigurieren kannst. Aber damit erzähle ich dir nur, was du schon weißt.
Sonassi erklärt die Wahl des Webserver wäre irrelevant, aber die setzen halt auch einen full page cache wie varnish davor, der dann wieder einen SSL Terminator braucht, also gleich mal 2 Layer mehr. Das würde ich mir erstmal sparen, erhöht nur die Komplexität und ermöglicht einem mehr falsche Konfigurationen zu machen.
Die schwören aber auf ihr Setup und behaupten es bringt einen nachweisbaren Vorteil, wenn es richtig konfiguriert ist. Und beim Aufwand für die Config verweisen sie auf ihre "quarterly audits" die richtig Asche kosten. Das deren Setup tatsächlich sinnvoll ist, halte ich dennoch für wahrscheinlich.

 

[theSplit]

@Shodan: Du solltest mehr schreiben, danke auch für deine Zustimmung... als Unbetroffener

Und fachlich kann ich über die ganzen Caching-Methoden leider nicht philosophieren, und hab da auch ehrlich gesagt keine Ahnung von. Aber du scheinst etwas mehr Ahnung zu haben.

Ein schöner Post. Danke. Und Kaffeeklatsch - wenn diese "Agentur"... zum Teil verstehe ich es, aber es regt mich auch auf - wenn ich Geld als Kunde bezahle für deren Dienstleistungen, bin ich denen voll ausgeliefert?

 

[sia]

Seltsam, dass die Anzahl der Requests in der Rechnung nicht vorkommen.

Dachte ich auch. Aber auf der anderen Seite ist das wohl egal, da die ja direkt nen 24-core mit 100GBit/s-Uplink empfehlen würden

Bleibe aber dabei: der Profi-Hoster, den du schon rausgesucht hast, fängt bei 16GB an. Vielleicht läuft es auch mit 8. Ist der Preisunterschied signifikant genug, dass es sich nicht lohnt etwas höher zu dimensionieren?

Gute Frage. Bei Netcup kann man den Server leicht "hochskalieren", aber nicht "runter". Daher würde ich lieber klein (6GiB RAM) anfangen und später™ upgraden. Mit 6GiB RAM sollte man ja wohl 12 gleichzeitige Requests hinbekommen, ansonsten ist Magento einfach scheiße und wir nehmen was anderes.

Ich hatte einen Kollegen, der ein Magento-Projekt betreut hat. Der hat auch ordentlich Hardware geordert, an vielen Stell-Schrauben gedreht, Konfigurationen optimiert, sich intensiv mit dem Datenbankindexes beschäftigt, Extensions ausprobiert, die Caches studiert und dann immer noch drüber geflucht.

Hach, so ist das mit den Webshops.

Wenn ich intensiv drüber nachdenke war das Hauptproblem damals aber, dass die Kundin gerne mal mit neuen Ideen (Anforderungen) um die Ecke kam, die Magento so nicht out of the Box konnte und mit Gegenvorschlägen, basierend auf dem was es konnte, nicht richtig zufrieden war.

Für meine Kunden bin ich hier eher der Problemlöser. Neue Anforderungen wird es nicht geben, die alten Anforderungen (Pflichten-/Lastenheft) sollen einfach nur stabil laufen.

Heißt, dass das "Major Version update" nicht abwärtskompatibel ist. Finde ich nicht überraschend, eher normal.

Joah, bei diversen CMS gibt's "einfache" Migrationstools, selbst bei Wordpress, was ja prinzipiell eher auf "billig" setzt.

Hat das System Maßanfertigungen drin? Die könnten schon bei einem Minor-Version Update auseinanderfallen.

Das hat es und ich weiß welche, die sollen ja gefixt werden. Dafür dann der PHP-Entwickler.

Lass mich raten: Doku gibt es auch nicht und auf dem Server liegen auch nur die nakten Dateien ohne GIT History?

Ach, ne Git-Historie liegt da schon, aber das ist die von der Agentur und nicht von dem, der die Änderungen ursprünglich betrieben hat.

Katze im Sack... Vielleicht sind die 10% ausfallenden Orders gar kein Problem des Speichers, sondern lassen sich auf irgend ein reingehacktes Feature zurückführen. Versuch mal die exakte Version des eingesetzten Magentos in clean aufzutreiben und diff die gegen den Stand vom Server um herauszufinden, ob da was manipuliert wurde.

Werde ich tun.

Alles in Allem mache ich aus einem Scheißhaufen einfach nur einen etwas kleineren Scheißhaufen. Vielleicht migriere ich auch tatsächlich auf WooCommerce/PrestaShop, einfach 4 shits and giggles und weil ich mich mit den beiden Systemen eher auskenne.

 

[electric.larry]

Kleiner nicht technischer OT Einwurf:

Ich würd mich definitiv mit der Agentur kurzschließen und fragen, was aus deren Sicht das Problem ist. Auch mit offenen Karten spielen und erklären, was der Kunde von dir möchte und fragen, warum die das nicht machen.

Aus langjähriger Erfahrung kann ich sagen, lässt man einen angenehmen Kunden nicht einfach ziehen und kümmert sich um seine Anliegen. Es hat also meist einen guten Grund, warum man einen Kunden nicht mehr weiter hilft. Wenn die Agentur sagt, der Kunde ist zu klein und unrentabel, OK. Oder vielleicht sind die einfach nicht auf Magento spezialisiert, dann wärs auch verständlich.

Es gibt aber auch die Sorte Kunde, die extrem beratungsresistent ist, immer nach 20 Uhr anruft und am Ende Preis drückt. Dem hat man schon 10 Mal gesagt, er muß den Shop upgraden, auf fetteren Server umsteigen, keine 20 MB Fotos hochladen, er ignoriert aber alle Warnungen und am Ende ist wieder der Techniker oder die Agentur schuld.

Lange Rede kurzer Sinn: Würd mir den Kunden genau ansehen und Erfahrung der Agentur einholen.

 

[Shodan]

Mit 6GiB RAM sollte man ja wohl 12 gleichzeitige Requests hinbekommen,

Sollte man von ausgehen können.
Wie viel RAM muss man für das Betriebssystem bereit halten? 1GB?
Wie haben Computer letztes Jahrtausen eigentlich überhaupt funktioniert?
"Langsam"

Heute gilt: Wer swappt verliert.
Dafür wird aber alles immer größer. Irgendwo hatte ich einen Rant von jemandem dazu gelesen...
*such* da: Things That Turbo Pascal is Smaller Than

Spoiler

The entire Turbo Pascal 3.02 executable--the compiler and IDE--was 39,731 bytes. How does that stack up in 2011 terms? Here are some things that Turbo Pascal is smaller than, as of October 30, 2011:

• The minified version of jquery 1.6 (90,518 bytes).
• The yahoo.com home page (219,583 bytes).
• The image of the white iPhone 4S at apple.com (190,157 bytes).
  ...

Datenbank? Auch 1GB?
Klingt irgendwie surreal, wenn das Datenbank-Dump nur 190MiB groß ist. Das passt da ja 5 mal rein, so viel kann die doch gar nicht fressen?!

Doch kann sie. Datenbanken sind auf massive Anfragemengen ausgelegt und haben die Tatsache das Speicher günstiger wurde gnadenlos ausgenutzt um die Performance zu verbessern und die wichtigen Kennzahlen zu optimieren. Wenn Oracle dann so schöne Dinge schreibt wie "The default configuration is designed to permit a MySQL server to start on a virtual machine that has approximately 512MB of RAM." kann ich halt nur noch den Kopf schütteln. Da steht ernsthaft "permit to start" nicht "run" oder "work" oder etwas ähnlich vertrauenerweckendes.

Beim Datenbanktunen bin ich aber auch überfragt. Geht ja mehr um die "Maximum possible memory usage". Auch hier gilt aber wieder: Produktion zu monitoren ist der bessere Ansatz um sinnvolle Werte zu bekommen, denn es gibt da ein paar üble Hacks. Mein Lieblingssatz aus dem Artikel: "can consume unbound amount of memory". Ohne das jetzt geprüft zu haben vermute ich aber einfach mal, dass Magento sowas nicht macht, oder zumindest nicht in relevanten Größenordnungen, bzw. die auch wieder freigibt.

Theorie: analog zum httpd kann man auch der DB erlauben mehr maximum zu haben, als das System tatsächlich hat und das bedeutet nicht, dass es dann direkt crasht. Eventuell crasht es nicht mal unter Last, weil die DB gar nicht weiß, was sie in 128GB Speicher reinschreiben soll.

Die Frage ist halt: was bedeutet "stabil"? Heißt stabil: das System hält einen synthetischen Lasttest aus? Heißt stabil "Das System ist, seit es in Produktion ist, nicht abgeschmiert" oder heißt stabil "Das System nutzt in Produktion nur die Hälfte des eingebauten Speichers, würde aber selbst dann noch laufen, wenn alle Bauteile bis zu ihrer jeweils konfigurierten Grenze maximal ausgelastet sind." In deinem Fall heißt stabiler wahrscheinlich, "die Orders schmieren nicht mehr ab". Verdacht: irgend ein schlecht gemachter Anbau ist die Ursache.

Für meine Kunden bin ich hier eher der Problemlöser.

Hey ein Kollege. Berichte am Ende mal, was du für ein WTF gefunden hast. Ist sicher lustig.

Gute Frage. Bei Netcup kann man den Server leicht "hochskalieren", aber nicht "runter". Daher würde ich lieber klein (6GiB RAM) anfangen und später™ upgraden.

Klingt nach nem Plan.


Nur so am Rande: sonassi ist gar nicht so 'n assi Deren Blog ist eine echt brauchbare Ressource für dein Projekt
https://www.sonassi.com/blog/quick-magento-performance-wins
https://www.sonassi.com/blog/knowledge-base/mysql-and-magento-peformance-tuning
...

Hier mal ein Auszug aus phpsysinfo: https://imgur.com/F2ZQDND

98% Memory Usage
(Aber noch 2.45 GB frei und der Swap ist leer... wachsendes Memory-Leak, riskant auf Kante, oder perfekt optimiert?)

Kaffeeklatsch

Spoiler

wenn diese "Agentur"... zum Teil verstehe ich es, aber es regt mich auch auf - wenn ich Geld als Kunde bezahle für deren Dienstleistungen, bin ich denen voll ausgeliefert?

Naja ein guter Dienstleister hat auch im Blick, was die Kunden wirklich brauchen und was das beste für sie ist. Da kann es auch mal zu Konflikten kommen, gerade wenn es um Dinge wie "Zugriff auf die Server" geht. Ich meine stell dir mal vor das sind voll die DAUs, die geben am Ende noch ihre eigene Datenbank an irgend 'nen Dritten weiter. Dinge wie Access- und Errorlogs sind halt auch Daten, die man nicht einfach mal per E-Mail verschicken sollte, nur weil jemand nett fragt.

Mal ne Frage, wenn man seriös arbeitet, ist man als Agentur nicht dazu "mehr oder minder" verpflichtet, einige Eckdaten des Projekts "sorgfältig zu übergeben?" (außer eigene Arbeit, speziell "Source code" ?)

Zu was man "verpflichtet" ist regelt man in der Regel vertraglich. Meine Vermutung: die meisten Veträge haben da große Lücken. Die Kundin sieht den Server als "ihren" an, schließlich bezahlt sie dafür. Der Dienstleister sieht den Server das "seinen" an, die Kundin zahlt dafür, dass die Seite im Netz ist. Der Vertrag ist ein wischiwaschi Konstrukt ohne technische Details. Ist der Dienstleister verpflichtet das Syslog rauszugeben?

 

[theSplit]

@Shodan: Klar, man muß "Know-how" auch nicht verschenken oder "Daten rausrücken", aber wenn man schon "aktiv gegen andere Anbieter" arbeitet, sagt das schon viel aus. Zumindest wenn der Kunde dafür bezahlt hat, die Produkte in der DB einpflegen und speichern zu lassen, sollte man die Datenbankinhalte, vielleicht, "rausrücken" und es tut ja auch nicht sonderlich weh zu sagen "1024 MB Limit" oder "512 MB" - das ist "theoretisch" nur eine Zahl, tut eigentlich nicht weh, noch sind die beiden Zahlen Staatsgeheimnisse und diese "freundliche Auskunft" wird den Dienst ja nicht einschränken. - Und mehr muß man dabei auch nicht erklären, da wäre dann @phre4k für verantwortlich das, sinnvoll, in Kontext zu setzen.

Also, ich weiß nicht, zeugt nicht gerade von Größe oder Stärke sich so quer zu stellen, und ja, in wie weit der Kunde für die Arbeitszeit bezahlt Daten einzupflegen, oder ob man indirekt auch das Recht "erwirbt" einen DB-Dump vom Anbieter zu bekommen auf Anfrage, lasse ich mal offen, da man das wohl auslegen kann, wie man will... (speziell auch wenn keine Modifikation durch den Anbieter stattgefunden hat und man die "Open Source Struktur" einsetzt) bzw. ist mir kein Gesetz bekannt, wenn es hart auf hart kommt. Aber es ist ziemlich "unsportlich".

 

[sia]

Bitte lasst die nichttechnische Diskussion abgesehen von Tipps zur Deeskalation (danke electric.larry an dieser Stelle), Spekulation über den Anbieter habe ich schon genug selbst angestellt

Die Frage ist halt: was bedeutet "stabil"? Heißt stabil: das System hält einen synthetischen Lasttest aus? Heißt stabil "Das System ist, seit es in Produktion ist, nicht abgeschmiert" oder heißt stabil "Das System nutzt in Produktion nur die Hälfte des eingebauten Speichers, würde aber selbst dann noch laufen, wenn alle Bauteile bis zu ihrer jeweils konfigurierten Grenze maximal ausgelastet sind."

Alle drei zusamme.

In deinem Fall heißt stabiler wahrscheinlich, "die Orders schmieren nicht mehr ab". Verdacht: irgend ein schlecht gemachter Anbau ist die Ursache.

Danke für den Link und ja, genau dies.

98% Memory Usage
(Aber noch 2.45 GB frei und der Swap ist leer... wachsendes Memory-Leak, riskant auf Kante, oder perfekt optimiert?)

Frei heißt an der Stelle "ungenutzt", die Memory Usage ist wohl eher buffers und cache.

 

[maggot]

Ich habe mir da jetzt nicht alles durchgelesen aber so pauschal wird man deine oben gestellte Frage nicht beantworten können, die Realität kennt hat nur der jetzige Hoster.... wenn überhaupt, meine Erfahrungen sind da eher das soviel Shops wie eben gehen auf eine Kiste geworfen werden und nur wenn es Beschwerden gibt, gegen ein "kleines" Endgeld auf einen Dedicated gesprungen werden kann.
Magento ist aber sehr resourcen Hungrig, verstehe eh nicht warum man sowas nutzt, mit 200 Artikeln, würde da eher zum JTL Shop greifen, ok damit kenne ich mich auch besser aus....hatte einen mit über 30000 Artikeln laufen.

Aber um mal Lösungsansätze vorzuschlagen: was spricht gegen eine Cloud Lösung.... also sowas wie die Jiffybox, da kannst du klein anfangen (über Nacht mal alles einspielen und die Domain dahin leiten) und dann beim Betrieb zuschauen....reichen die Ressourcen nicht, so kannst du die einfach LIVE hochdrehen und am Ende so nach ein zwei Wochen Betrieb kommt raus, was genau ein Server leisten müsste um den Shop am laufen zu halten......


Just my 2 cents...

 

[sia]

Ich habe mir da jetzt nicht alles durchgelesen aber so pauschal wird man deine oben gestellte Frage nicht beantworten können, die Realität kennt hat nur der jetzige Hoster....

Ist mir schon klar, siehe oben

Hatte vor, das mit "mage-perftest" zu benchmarken (alter Anbieter / neuer Server).

wenn überhaupt, meine Erfahrungen sind da eher das soviel Shops wie eben gehen auf eine Kiste geworfen werden und nur wenn es Beschwerden gibt, gegen ein "kleines" Endgeld auf einen Dedicated gesprungen werden kann.

Genau so ist es. "klein" hast du auch folgerichtig in Anführungszeichen gesetzt.

Magento ist aber sehr resourcen Hungrig, verstehe eh nicht warum man sowas nutzt, mit 200 Artikeln

Historisch, und unser Warenwirtschaftssystem unterstützt:

ePages
Gambio GX
Koobi
Magento
modified eCommerce
osCommerce
PrestaShop
Shopware
Strato
VirtueMart
xaranshop
xtCommerce

Magento ist beim Funktionsumfang ebenfalls ungeschlagen.

Aber um mal Lösungsansätze vorzuschlagen: was spricht gegen eine Cloud Lösung.

Nichts, gute Idee.