Ich werde beißen.
Diese erste Antwort vom Webserver muss in Großbritannien unter 200 ms eingehen. Derzeit
gibt es kein Frontend für die Website, sie ist frei von Stilen und Bildern .
Sie werden diese Zahlen nicht ohne die Hilfe von Varnish oder FPC (oder beidem) erreichen. Ich würde mit Sicherheit hoffen, dass die Abbildung nicht auch statischen Inhalt enthalten muss (wenn Sie sich entscheiden, ihn hinzuzufügen) - da dies so gut wie unmöglich ist (es fehlen nur wenige bis gar keine Bilder / js / css).
Wir kommen um 800ms an.
Es wird auch auf Nginx mit Lack gefahren
Sie haben Varnish falsch konfiguriert.
Eine richtig konfigurierte Installation von Varnish führt zu Ladezeiten von <100 ms (näher an <10 ms).
In der Tat, für Magento sollten Sie so etwas erwarten,
Wenn ein Kunde nicht eingeloggt ist ...
Dh. Keine einmalige Sitzung erstellt (zum Warenkorb / Wunschzettel hinzufügen, einloggen usw.)
--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
Uncached Mage default cache Partial FPC cache Total FPC cache Varnish
Wenn ein Kunde angemeldet ist ...
Dh. Eine einmalige Sitzung erstellt haben (angemeldet, Artikel im Warenkorb usw.). An diesem Punkt wird Varnish wahrscheinlich ausgeschaltet sein. Wenn Sie sich für die Verwendung von ESIs entschieden haben - abhängig von den umgekehrten Aufrufen -, kann diese entweder eine ähnliche Seitenladezeit beibehalten wie der FPC-Cache (aufgrund des Bootstrap-Overheads) - oder die Seitenladezeiten erhöhen, ohne dass sie zwischengespeichert werden.
--1.4s--------0.8s-----------------0.6s--------------
Uncached Mage default cache Total FPC cache
Es geht nicht darum, den Lack abzustimmen - es geht darum, "dass Sie überhaupt nichts zwischenspeichern" .
Die idealen Magento Server Konfigurationsdateien
Es gibt keinen, na ja, nicht ganz.
Wir betreiben über 400 Server, allesamt reine Magento-Stores - unterschiedlicher Größe und Kapazität. Und es ist selten, dass die Konfigurationsdateien, die wir auf einer haben, mit denen einer anderen übereinstimmen. Das liegt daran, dass nicht alle Unternehmen gleich sind.
Engpässe können sich aus vielen verschiedenen Gründen bilden:
- Hohe Anzahl von gleichzeitigen Besuchern mit aktiven Sitzungen
- Opfer von "schlechten" Crawl-Bots, die die notwendige, unschätzbare Last erzeugen
- Hoher Anteil geschichteter Navigationstreffer
- Hohe Anzahl von Suchanfragen
- Hohes Transaktionsvolumen pro Stunde
- Schlecht gebaute Vorlage
- Zu viele / langsame / sperrige Erweiterungen von Drittanbietern
- Veraltete eingehende Links führen zu einem hohen Anteil von 404 Treffern
- Netzwerkschnittstellenkapazität am Limit
- Großer / komplexer Katalog (viele Produkte / Kategorien / Attribute)
Bei Geschäften in allen Bereichen dieses Spektrums hat jeder eine andere Herangehensweise, um eine optimale Leistung zu erzielen.
Um die oben beschriebenen Probleme zu lösen; Wir werden absichtlich vermeiden, nur "mehr / bessere Hardware" anzugeben.
- Verwenden Sie eine FPC, die über die von Varnish hinausgeht
- Filtern / blockieren Sie fehlerhafte Bots am Netzwerkrand - oder leiten Sie alle Anfragen an Varnish um, unabhängig vom Cookie-Status / der URL
- Ändern Sie die Standardnavigation in SOLR, und machen Sie die Filter für die Navigation in Ebenen abhängig
- Ändern Sie die Aktiensuche in SOLR
- Verteilen Sie die MySQL-Last auf die Master / Slave-Konfiguration - tun Sie dies nur, wenn Sie garantiert haben, dass die Browserbelastung von Varnish / FPC absorbiert wird
- Erstellen Sie die Vorlage neu
- Zieh sie aus
- Überwachen Sie die Zugriffsprotokolle kontinuierlich und schreiben Sie die URLs bei Nginx / Varnish vor der Auslieferung neu. Wenn Sie dies auf Nginx-Ebene tun, stellen Sie sicher, dass Varnish 301/302 Weiterleitungen zwischenspeichert.
- Teilen Sie statische Inhalte auf ein CDN auf oder verbessern Sie die Konnektivität
- Füge mehr Hardware hinzu (nun, wir mussten es irgendwann sagen)
Aus diesem Grund werden Sie wahrscheinlich feststellen, dass es keine Nginx-Konfigurationsdatei, PHP-FCGI-Pool-Konfigurationsdatei, MySQL-Konfigurationsdatei oder Lack-Konfigurationsdatei geben wird, die gleich sein werden. Verbinden Sie dies mit der Hardware, die sich selbst ändert. Verfügbarer Arbeitsspeicher, E / A-Leistung (Festplatte und Netzwerk) und CPU - und Sie werden feststellen, dass es geringfügige Unterschiede gibt, die zu dem gewünschten Leistungsgewinn von 400% führen -, aber keine schnelle Antwort, die Sie direkt online finden.
Sie können das von Peer 1 gesponserte Magento- Whitepaper zu Performance kopieren und einfügen (wir würden es nicht empfehlen). Ich hoffe, dass die Einstellungen den verfügbaren Speicher, die Thread-Limits, die TCP / IP-Zustände und die E / A-Kapazität nicht überschreiten und zu einer geringeren Leistung führen als eine Vanille-Apache / mod_php-Konfiguration.
Also lasst uns weitermachen.
Der ideale Magento Server Stack
Dies ist wahrscheinlicher, um Sie näher an die Realität zu bringen. Ein gutes Beispiel, um dies zu demonstrieren, ist die Konfiguration eines speziellen Magento-Betriebssystems, MageStack
Nehmen Sie die separaten Unterkomponenten und Sie haben eine Liste der optimalsten / kritischsten Software, wenn sie richtig konfiguriert ist , um einen Magento-Store zu betreiben. Vor allem:
Firewall, DOS-Filter, Load Balancer, Firnis, Nginx, PHP, Redis, Memcached, MySQL
Wenn Sie also fragen:
Was ist das beste Magento Server Setup?
Was genau ist dein Ziel?
- Hohe Verfügbarkeit
- Verlässlichkeit
- Einfache Administration
- Performance
- Skalierbarkeit
Genug Vorlesungen, wie würden wir das machen?
Um die Antwort auf einen Serverfehler teilweise widerzuspiegeln , gehen Sie ähnlich vor. Sie haben 3 Server zur Verfügung - orientieren Sie diese also zuerst so optimal wie möglich. Wir werden eine hochverfügbare Lösung vermeiden, da dies den Rahmen dieser Antwort sprengt.
Die für eine Konfiguration mit mehreren Servern erforderlichen Unterkomponenten sind:
- Firewall
- Lastenausgleicher
- Webserver
- MySQL Server
- Gemeinsamer Speicher
Deshalb werden wir einige Systeme für verschiedene Zwecke einsetzen. Die PCI-DSS-Konformität schreibt für jeden Server eine Rolle vor. Mit 5 Rollen und 3 Servern sind Sie sofort in Gefahr. MageStack umgeht dies mithilfe der Virtualisierung - Sie könnten das Gleiche tun.
Server 1: Load Balancer + Webserver
Server 2: Webserver
Server 3: Datenbankserver
Ohne geringe Latenz und erhebliche Netzwerkbandbreite (> 1 Gbit / s, <125 µs) anstelle eines gemeinsamen Speichers ist es besser, das Stammverzeichnis des Speichers auf jedem Computer zu speichern und die Daten entweder in Echtzeit zu replizieren ionotifyoder zu verwenden ein cronJob. Auch hier vermeiden wir Netzwerkdateisysteme wie NFS oder replizierte Blockgeräte wie Gluster oder DRBD, da eine umfassende Optimierung und eine angemessene Netzwerkbandbreite erforderlich sind.
Lack muss so nah wie möglich vorne sitzen. Varnish kann SSL jedoch nicht entschlüsseln. Kombinieren Sie es also mit einem SSL-Terminator. Nginx, Pound, Stunnel, Stud usw. Der eingebaute Load Balancer in Varnish ist nicht besonders gut - aber für eine Einrichtung mit zwei Servern ausreichend.
Nginx + PHP-FPM ist in Ordnung, aber trinken Sie nicht zu viel von der Nginx Kool-Hilfe. Es wird fast identisch mit einer traditionellen Apache / mod_php-Konfiguration ablaufen. Hier ist eine gute Lektüre, warum man Nginx nicht verwenden sollte . Nginx ist gut, sehr gut, aber es ist sicherlich kein Engpass in einem Magento-Geschäft - und angesichts seiner Komplexität und des Mangels an nativem Magento-Support. Die meisten unerfahrenen Systemadministratoren würden von der Verwendung von Apache / mod_php über alles andere profitieren. Dies scheint eine archaische Empfehlung für die Verwendung von PHP-FPM zu sein - aber unsere Leistungstests haben gezeigt, dass die Leistung mit der Nginx-Lösung nur ~ 7% schneller ist - wenn sie richtig konfiguriert ist. Das Tuning und die Erfahrung, die für ein leistungsstarkes, zuverlässiges Nginx / PHP-FPM-Setup erforderlich sind, sind ziemlich umfangreich, um Apache / mod_php zu übertreffen. Was auch immer Sie verwenden, ist Ihr Anruf.
Der Datenbankserver ist einfach, MySQL. Wie bereits erwähnt, wird jedoch eine Master / Slave-Konfiguration empfohlen, wenn Sie eine hochgradig konvertierende Site haben. Ob Sie diesem Ansatz folgen sollten, erfahren Sie in diesem Artikel .
Dann werden Ihre peripheren Back-End-Caches, Memcached und Redis. In kleineren Geschäften führt das Speichern von Sitzungen in einer Memcache-Instanz und des schnellen Back-End-Caches in einer anderen zu guten Leistungsvorteilen. Wir raten davon ab, die Cache-Tags in einem langsamen Backend zu speichern, da dies mehr Probleme verursacht als es gibt. Bei einer Memcached-Konfiguration müssen Sie also auf das Cache-Tagging verzichten . Stattdessen verwenden wir eine Konfiguration wie diese .
Redis ist nicht in Magento integriert, aber mit der Erweiterung von Colin Mollenhour - eine bessere Lösung als Memcache - werden Cache-Tags, Sitzungsspeicher und sogar permanenter Cache-Speicher unterstützt - dies ist nicht ganz so flüchtig wie Memcache . Aber es hat seine Nachteile. Wir haben in großen Produktionsgeschäften (> 500 Bestellungen / Stunde,> 30.000 Unikate / Stunde) festgestellt, dass sich der Cache (und die Tags) sehr schnell füllen können und der LRU-Mechanismus nach Erreichen des Sättigungspunkts etwas ausfällt ( trotz unterschiedlicher Einstellungen) und verursacht einen massiven unmittelbaren Engpass. Es ist daher ratsam, alte Datensätze regelmäßig manuell zu bereinigen.
Also, welche Hardware sollte für was verwendet werden?
Webserver: Schnellste CPU, die meisten CPU-Kerne, Verhältnis von 2 GB RAM / Core
DB-Server: Schnelle CPU, schnellste Festplatten-E / A, die meisten RAM
Wenn Sie also Ihre 3 Maschinen für mehrere Zwecke einsetzen, ist das beste Layout:
Server 1: SSL Terminator -> Lack -> Nginx / Apache> PHP
Server 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Server 3: MySQL
Bezüglich der spezifischen Konfiguration jeder Anwendung. Das hängt von Ihren Hardwarespezifikationen, der Komplexität Ihres Geschäfts, Ihrem Besuchertyp und der Art des Besuchers sowie dem enormen Besucheraufkommen ab.