Sie tauchen hier in eine weite Welt der Optimierung ein, und es gibt mit Sicherheit keinen einheitlichen Ansatz.
Leistung definieren
Meinen Sie die Ladezeit der Seite für einen einzelnen Benutzer oder die Gesamtkapazität / Gesamt-Parallelität? Die beiden sind sehr unterschiedlich - und nicht eng miteinander verbunden. Es ist durchaus möglich, ein schnelles Geschäft mit begrenzter Kapazität zu haben. oder ein langsamer Laden mit viel Kapazität.
Wenn Sie sich also an einen der beiden Leistungstypen wenden:
- Vom einzelnen Benutzer wahrgenommene Ladezeit der Seite
- Gesamtkapazität / Nebenläufigkeit
Sie müssen sich unabhängig voneinander mit ihren eigenen Lösungen auseinandersetzen - zumal jede ihre eigenen Engpässe hat.
Nehmen wir an, Sie haben einen kompetenten Host, der die anderen Aspekte Ihres Servers bereits optimal für Ihr Geschäft konfiguriert hat.
Vom einzelnen Benutzer wahrgenommene Ladezeit der Seite
Ist MySQL der Engpass
Nr. Nicht direkt. Beim Testen der Ladezeit einer Seite dreht sich in den meisten Fällen alles um die Latenz - nur die Caches werden getroffen. Hier geht es also darum, die Latenz zu minimieren.
- Passen Sie die Größe des MySQL-Caches entsprechend an (es gibt keine richtige Antwort, wir passen die Einstellungen monatlich und pro Geschäft völlig anders an).
- Reduzieren Sie die Netzwerklatenz. Für 64-Byte-Frames; 51,2 us für 10 Mbit / s, 5,12 us für 100 Mbit / s und 4,096 us für 1 Gbit / s. Dies ergibt eine Verbesserung von 20%, wenn lediglich von 100 Mbit / s auf 1 Gbit / s umgestellt wird. s1
- Erhöhen Sie die Netzwerkkapazität. Sie werden überrascht sein, wie viele Megabyte pro Sekunde zwischen einem Web- und einem DB-Server ausgetauscht werden, normalerweise mit mehr als 10 MB / s - daher sind mindestens 100 MB / s erforderlich s1 . Oder verschieben Sie einfach den DB-Server lokal.
- SOLR verwenden. Externe Engines sind manchmal besser geeignet, SOLR ist sicherlich schneller für größere Kataloge (und ich würde betonen, größere Kataloge ). Sogar nicht optimiertes SOLR erzeugt mehrschichtige Navigations- und Suchergebnisse schneller als MySQL.
Diese Änderungen wirken sich jedoch nur geringfügig auf die Ladezeit der Seite aus - wo der Engpass wirklich woanders liegt.
- Optimieren Sie die Anwendung. Magento hat einige ziemlich große Fehler bei der Art und Weise, wie Sammlungen erstellt und zwischengespeichert werden. Wir sind auf eine Reihe großer Kernprobleme gestoßen, die die Leistung beeinträchtigen können. In einigen Fällen konnte durch einfaches Entfernen der Produktanzahlanzeige in den Ergebnissen der mehrschichtigen Navigation das Laden einer großen Sammlung in 2 Sekunden beschleunigt werden .
- Überprüfen Sie die langsamen MySQL-Protokolle. Überprüfen Sie langsame Abfragen und fügen Sie bei Bedarf Indizes hinzu. Der Unterschied zwischen der Ausführung einer komplexen Abfrage mit mehreren Joins mit und ohne entsprechende Indizes kann mehrere zehn Sekunden betragen .
Die Anwendung ist der Engpass. Nicht die Software. Die bloße Verbesserung des Kerncodes oder das Verringern des Umfangs Ihrer Vorlage hat weitaus dramatischere Auswirkungen auf die Leistung als jede Änderung der MySQL-Konfiguration.
Womit würden wir uns nicht befassen?
- Speicher-Engine wechseln. MariaDB und Percona nutzen dieselbe InnoDB-Engine - Percona XtraDB. Sie können als ein und dasselbe behandelt werden. In Bezug auf die Ausführungszeit einer einzelnen Abfrage spiegelt die Leistung genau einen Vanilla-MySQL-Build wider. Dies kommt unter Last / Nebenläufigkeit ins Spiel.
- Einen MySQL-Slave ausführen. Dies wird die Leistung nur verbessern, wenn sich der Slave physisch näher (aus Netzwerksicht) befindet oder der Slave über eine bessere Hardware als der Master verfügt. Dies kommt unter Last / Nebenläufigkeit ins Spiel.
- Ausführen eines externen DB-Servers. Dies ist bei weitem der schlechteste Rat, den wir von vielen Gastgebern / Agenturen immer wieder erhalten haben. Bis Sie eine Obergrenze für Hardware / Ressourcen erreicht haben oder mehrere Webserver (sprich: Hochverfügbarkeit) haben, ist MySQL auf dem lokalen Computer für einen Magento-Store eine gute Idee. Es reduziert den gesamten Netzwerkaufwand und die Latenz. Selbst ein 100-Gbit / s-Netzwerk (ja, einhundert Gigabit pro Sekunde) lässt sich hinsichtlich Rohvolumen , Durchsatz und Latenz nicht mit einem lokalen Unix-Socket vergleichen.
s1 Nur für separate Datenbankserver. Gilt nicht für lokale DB-Server.
Gesamtkapazität / Nebenläufigkeit
Ist MySQL der Engpass
? Aber erst wenn Sie Ihre PHP-Leistung und -Kapazität auf einen Punkt gebracht haben, an dem MySQL die Dinge verlangsamt. Wenn Sie Varnish und FPC richtig konfiguriert haben (lassen Sie uns nicht wissen, wie viele Fehlversuche wir mit beiden gesehen haben), wird MySQL zu einem Engpass.
Also zusätzlich zu den obigen Modifikationen.
- Ändern Sie die MySQL-Engine. XtraDB kann sich unter Last auszeichnen und zeigt echte Vorteile gegenüber einer Standard-MySQL-Distribution.
- Bleiben Sie mit MySQL auf dem Laufenden. 5.5 schneidet unter Last besser ab als 5.0.
- Ändern Sie den PHP MySQL-Treiber. PHP 5.3 und neuer hat einen nativen MySQL-Treiber, aber unter bestimmten Umständen haben wir PHP 5.2 mit dem separaten Treiber gefunden, der MySQLND für Magento übertrifft. Testen Sie es selbst
- Suchmaschine ändern. Die Verlagerung der Suche nach SOLR / Sphinx (oder sogar nach externen Diensten von Drittanbietern) kann die Belastung durch nicht transaktionale Lasten (dh Personen, die keine Bestellungen aufgeben) erheblich verringern.
- Ändern Sie die geschichtete Navigations-Engine. Auch hier ist SOLR eine brillante Engine für die mehrschichtige Navigation und aufgrund seiner nicht sperrenden Eigenschaften weitaus schneller als MySQL.
- Fügen Sie einen MySQL-Slave hinzu. Dies tut Hilfe - Browsing (nicht transaktions) Last, aber nicht helfen, mehr Aufträge pro Stunde verarbeiten - wie es auf der Master - Prozess angewiesen ist und repliziert diese Daten
Womit würden wir uns nicht befassen?
- Meister / Meister. Aufgrund des ziemlich hohen Wendepunkts der Hardwaresättigung eines Master / Slave-Setups (über 1000 Bestellungen pro Stunde) war es nie erforderlich, Master / Master in der Produktion zu verwenden. Wir haben umfangreiche Tests durchgeführt, haben jedoch nie festgestellt, dass dies unter Performance-Gesichtspunkten von Vorteil ist. Angesichts der mit Master / Master verbundenen Risiken und Probleme lohnt es sich einfach nicht.
Skalierbarkeit von Lesen und Schreiben
Der letzte Absatz führt zu einem wichtigen Bereich der Lese- und Schreibskalierbarkeit. Die Skalierung der Lesevorgänge kann ohne großen Aufwand mit der Hinzufügung von immer mehr Slaves ziemlich unbegrenzt durchgeführt werden.
In Anbetracht der Tatsache, dass Magento ein Verhältnis von Lese- zu Schreibvorgängen von etwa 0,1% aufweist, sollten Schreibvorgänge kein großes Problem darstellen. Aus diesem Grund habe ich mich nicht mit MySQL Cluster und seinen cleveren Funktionen wie dem automatischen Sharding (Aufteilen von Tabellen auf separate Maschinen) befasst.
Hardware, Hardware, Hardware
Hardware ist mit Sicherheit die schnellste Antwort, wenn es um Verbesserungen geht. Daher habe ich sie in beiden Szenarien bewusst nicht erwähnt.
Aber alle Software-Änderungen auf der Welt werden keinen Unterschied machen, wenn Ihre zugrunde liegende Hardware nicht ausreicht. Das könnte bedeuten ...
- Schalter mit geringer Qualität und begrenzten Puffern
- Überlastete Netzwerkverbindungen
- Geografisch entfernte Server
- Schlechte Netzwerk-QoS / CoS
- Begrenzte Gesamtmenge an RAM
- Niedrige Speicherbandbreite RAM
- HDD-Subsystem mit niedrigem IOP
- Software-RAID-Controller
- CPU mit niedriger Taktrate
- Chipsatz mit niedriger Bandbreite
- Hardware-Virtualisierung (fast alle Typen außer Kernel-Level-Virtualisierung)
Heutzutage gibt es eine sehr hohe Obergrenze dafür, wie hoch Sie tatsächlich auf Hardware skalieren können. Ignorieren wir den Mythos der unendlichen Skalierung "in der Cloud", da Cloud-Hardware eher mittelmäßig ist. Zum Beispiel sind die Flaggschiff-Modelle von Amazon nur 12 Kerne bei 3,3 GHz. Abgesehen davon sind einige sehr leistungsstarke Server verfügbar - unser Top-Server verfügt über 160 Kerne und 2 TB (ja, Terabyte) RAM. Wir haben noch niemanden gesehen, der diese Möglichkeiten übertrifft.
Sie haben also einen enormen Spielraum für die vertikale Skalierung, bevor Sie überhaupt die horizontale Skalierung in Betracht ziehen müssen.
Das sich ständig bewegende Ziel
Erwähnenswert ist, dass bei der Suche nach Leistung der Engpass immer in Bewegung bleibt.
Für einen Lager Magento Store.
Schalten Sie die Caches ein. PHP ist der Engpass
Fügen Sie einen Backend-Cache hinzu. PHP ist der Engpass
Fügen Sie einen Ganzseiten-Cache auf Anwendungsebene hinzu. PHP ist der Engpass
Fügen Sie einen Front-End-Cache auf Serverebene hinzu (z. B. Lack). MySQL ist der Engpass.
Fügen Sie eine alternative Such- / Ebenen-Navigationsmaschine hinzu (z. B. SOLR / Sphinx). PHP ist der Engpass.
Fügen Sie weitere Anwendungsserver hinzu. MySQL ist der Engpass
Fügen Sie einen MySQL-Slave hinzu. Front-End-Cache ist der Engpass.
Fügen Sie weitere Front-End-Cache-Server hinzu. PHP ist der Engpass.
Fügen Sie weitere Anwendungsserver hinzu. SOLR / Sphinx ist der Engpass
Und so weiter.
Es wird so ziemlich ein Fall von Spül-Wasch-Wiederholung. Es ist jedoch klar, dass MySQL sicherlich nicht die erste Anlaufstelle für Optimierungen ist - und tatsächlich nur dann zum Tragen kommt, wenn MySQL proportional zu PHP mehr CPU verbraucht - und dies NUR dann, wenn sowohl FPC als auch Varnish verwendet werden und die Server verarbeiten nur Bestellungen und nicht viel anderes (weil sich alles andere in Caches befindet).
Nehmen Sie keine Änderungen blind vor
Wenn Sie einfach einen MySQL-Slave hinzufügen, weil Sie oben lesen, dass dies helfen wird, können Sie Leistung und Zuverlässigkeit auf einer riesigen Ebene kosten. Ein überlastetes Netzwerk, ein Slave-Server mit niedrigen Spezifikationen oder sogar falsche Einstellungen können Replikationsprobleme verursachen, die Ihren Shop langsamer machen als ursprünglich - oder Synchronisierungsprobleme zwischen Master und Slave verursachen.
Um die Dinge ins rechte Licht zu rücken - einige Beispiele aus der Praxis.
Beispiel 1 - 300 Bestellungen pro Stunde
Wir haben die folgende Hardware verwendet, um 300 Bestellungen pro Stunde zu bearbeiten. Und erst zu diesem Zeitpunkt mussten wir einen dedizierten MySQL-Server und einen lokalen MySQL-Slave hinzufügen.
1 Server
CPU: 2x Intel E5-4620
RAM: 64 GB Festplatte: 4x 80 k IOP / s SSDs
RAID: Hardware-RAID 10
Magento-Version: Magento EE
Betriebssystem: MageStack
Während der gesamten Zeit blieben die Durchschnittswerte der Ladung unter 3,00.
Beispiel 2 - 180 Bestellungen pro Stunde
Erst vor zwei Tagen hat ein neuer Kunde von uns leicht einen großen Verkehrsanstieg verzeichnet. Verarbeitung von 180 Bestellungen pro Stunde mit einem einzelnen Server und Magento Community Edition .
1 Server-
CPU: 2x Intel E5-4620
RAM: 64 GB Festplatte: 4x 80 k IOP / s SSDs
RAID: Hardware RAID 10
Magento Version: Magento CE
Betriebssystem: MageStack
Website: Wellgosh.com
Während der gesamten Zeit blieben die Durchschnittswerte der Ladung unter 6,00. Die Last war in diesem Szenario höher und das war auf einige Faktoren zurückzuführen.
- Es wurde keine store-seitige Abstimmung wie in Beispiel 1 durchgeführt
- Das Fehlen einer FPC auf Anwendungsebene
In Anbetracht der Aktualität haben wir immer noch die detaillierten Statistiken, um mithilfe von Diagrammen Feedback zu geben. Diese enthalten eine hervorragende Darstellung der Lastverteilung auf die Hauptkomponenten einer separaten Magento-Architektur (Load Balancer, Webserver, Datenbankserver usw.) unter Verwendung von MageStack ).
Also von vorne nach hinten ... das Datum, das Sie sich ansehen möchten, ist am 22. Februar um 12:00 Uhr.
Firewall-Pakete
Lack Verkehr
Nginx Verkehr
MySQL laden
CPU-Auslastung
Und vor allem Lastverteilung
Dieses Bild sagt wirklich alles. Und es ist, dass MySQL sicherlich keine Last ist - zumindest noch nicht. Konzentrieren Sie sich daher in unserem Rat auf Ihre Leistungsanliegen, es sei denn, Sie bearbeiten mehr als ein paar tausend Bestellungen pro Stunde.
Und zusammenfassend
Leistungsänderungen sind nicht "one size fits all". Es geht darum, Ihre aktuellen Engpässe zu analysieren und subtile Änderungen / Anpassungen vorzunehmen, um sie an Ihr Geschäft und Ihre Infrastruktur anzupassen.
Abgesehen von der Leistung bietet Percona noch weitere Vorteile
Wir verwenden fast ausschließlich Percona XtraDB. Wir führen kundenspezifisch kompilierte MySQL-Builds aus, die wir speziell für Magento entwickelt haben und die Percona während des Prozesses zu Rate gezogen haben. Aber es war nicht nur die Leistung, die diese Wahl beeinflusste.
- Das Percona-Toolkit
- pt-query-digest
- xtrabackup
- etc.
- Häufigkeit der Percona-Freisetzung
- Percona beratende Unterstützung
- Der Warm-Cache wird mit der Beibehaltung des InnoDB-Pools neu gestartet
Und vieles mehr. Die Verwendung gegenüber MySQL hatte also andere Vorteile als nur die Leistung. Tatsächlich war und ist MySQL das am wenigsten von uns betroffene Unternehmen bei der Suche nach Leistung und Stabilität.
Zuweisungen : wellgosh.com , sonassi.com , iebmedia.com .