Leistungsproblem mit 1k bis 10k Websites / Stores

9

Ich versuche einen Weg zu finden, um die Magento-Leistung zu verbessern, wenn die Anzahl der Websites / Geschäfte 1k überschreitet und mein Ziel bei 10.000 liegt. Hier sind einige Fragen; Tipps / Hilfen sind herzlich willkommen!

  1. Das Hinzufügen neuer Websites / Geschäfte ist langsam.
    Ich kommentiere $ this-> cleanModelCache () in _afterSave () in Mage_Core_Model_Abstract aus, und die Situation scheint besser zu sein, wird aber mit zunehmender Anzahl von Websites / Geschäften langsamer. Und ich weiß nicht, wie sich dies in Zukunft auf das gesamte System auswirken würde.

  2. API-Anrufe werden langsam.
    Einer der Hauptprozesse ist die Bestellung; Mein angepasstes Modell behandelt dies, indem es einige Daten verarbeitet und im Wesentlichen Verkaufs- / Angebotsmodelle und Verkaufs- / Servicemodelle verwendet. Der Prozess beginnt mit Oauth. Sowohl Oauth als auch die Bestellung dauern länger, wenn die Anzahl der Websites / Geschäfte zunimmt und der Speicherverbrauch größer zu sein scheint. Hat dies etwas damit zu tun, dass Mage die Konfigurations-XML lädt und die Konfigurationsdaten mit zunehmender Anzahl von Websites größer werden?

  3. N98-magerun dev öffnen: Konsole dauert länger; Ich kenne die Ursache nicht.

  4. Das Speichern der Konfiguration über das Admin-Panel dauert länger. Ich weiß nicht, wie ich es verbessern soll.

Ist es möglich, die Art und Weise zu rekonstruieren, wie Magento Konfigurationsdaten generiert und lädt, um den Speicherverbrauch zu senken? Ist dies einer der Faktoren, die Leistungsprobleme für meine Situation verursachen?

Aktuelle Magento-Instanz: Version = Magento EE 1.14.2.4;
Konfigurationscache ein; anderer Cache aus;
Verwenden von MySQL 5.6 und MongoDB (für catalog_category_entity, catalog_product_entity, core_website);
Anzahl der Websites = Anzahl der Geschäfte = Anzahl der Aufrufe = 1024;
Anzahl der Produkte = 4501;

Vielen Dank im Voraus!

Jack.W
quelle
2
Warum kann Magento Support Ihnen nicht helfen?
MagenX
Wie bekomme ich Hilfe von ihnen? Ich bin neu in der Community .. danke!
Jack.W
1
Sie haben eine Enterprise-Version, sind sich nicht sicher, wo Sie sie bekommen, aber wenn keine Magento-Unterstützung dahinter steckt, verschwenden Sie einfach Geld und Zeit. Sie müssen sie gut in die Kugeln schlagen, damit sie wie Kaninchen laufen, die Ihnen helfen. Was bringt es, eine Enterprise-Version zu haben?
MagenX
1
aber offensichtliche Antwort auf Ihre Frage ist - separate Magento-Shops mit separaten Datenbanken, wie Chargen pro 10-20 Shops ...
MagenX
Ah richtig ... ich werde meinen Chef nach dem Konto fragen ... haha.
Jack.W

Antworten:

3

Einer der Gründe, warum es langsam wird, ist, dass die Konfiguration für jedes Geschäft aus / config / sites und / config / global dupliziert wird und der Code dafür nicht im geringsten effizient ist. Jede Änderung der Einstellungen kann dazu führen, dass mehrere 10 Minuten, wenn nicht Stunden, die Leistung und den Durchsatz verringern. Effizienter zu werden bedeutet im Grunde, dass Ben Marks hinter Ihnen her ist ... und nicht auf gute Weise.

Wenn Sie diesen Weg gehen, ist es am einfachsten, 10.000 Magento-Installationen zu haben und eine Art Broker zu haben, der Anfragen an die entsprechende Website delegiert. Dies hängt natürlich davon ab, was Ihr tatsächlicher Anwendungsfall ist.

[hinzugefügt]

Abhängig vom Anwendungsfall können Sie möglicherweise Kategorien als Pseudospeicher verwenden. Sie können dann technisch Layout-XML verwenden, um das Thema pro Geschäft zu ändern. Aber dann würden Sie auf die Einschränkung der Kaufabwicklung stoßen. Alle Geschäfte müssten die Kasse teilen.

In jedem Fall sind 10.000 Magento-Stores machbar, da dies nicht unmöglich ist. Aber es wird eine schwierige Straße sein, egal welchen Weg Sie wählen.

Kevin Schroeder
quelle
Hallo Kevin, danke für deine Antwort! Ja, ich sehe den Code, der den Konfigurationsbaum aktualisiert. Dies ist loadToXml (), wenn ich mich nicht irre. Mein Gedanke ist; und Sie sagten, es sei keine gute Idee, es zu ändern? Was meinst du damit, dass Ben Marks nach mir kommt? Es scheint auch, dass jede http-Anfrage, die an Magento kommt, irgendwann den Konfigurationsbaum lädt. Ist das richtig? Wie kann ich die Größe verkleinern? Ich sollte wahrscheinlich darüber nachdenken, 10.000 Magento-Instanzen zu erhalten ... irgendwelche Gedanken darüber, wie viel Ressource das benötigen würde? Vielen Dank Kevin!
Jack.W
Aber 10.000 Magento-Installationen bedeuten 10.000 MySQL-Instanzen, oder? Ich habe keine Ahnung, wie das geht oder ob es eine gute Idee ist ..
Jack.W
1
Nein, es würde bedeuten, 10.000 MySQL-Datenbanken zu haben, aber alle 10.000 könnten sich in einer einzigen MySQL-Instanz befinden.
Christian
1
Die "Ben Marks", die nach Ihnen kommen, sind ein Verweis auf diese camo.githubusercontent.com/…
Kevin Schroeder
1
10.000 Magento-Installationen bedeuten 10.000 MySQL-Datenbanken, die jedoch verteilt wären. Es wäre VIEL einfacher, Skripts für die Bereitstellung von 10.000 einzelnen Magento-Installationen zu erstellen, als den vorhandenen Kerncode für 10.000 Speicher zu verwenden.
Kevin Schroeder
1

Sie können versuchen, den Kern zu hacken und Website-Cache-Splits zu aktivieren. Sie können versuchen, die Datenbank zu hacken und Konfigurationsinformationen im Speicher zu speichern. Sie können versuchen, den Konfigurationscache durch etwas Intelligenteres zu ersetzen - beispielsweise das Zwischenspeichern der Informationen aus den XML-Dateien [die statisch sind und für alle Websites und Geschäfte gelten], während Sie die Überschreibungsdaten dynamisch abrufen.

Ich bin ein Server-Typ, also würde ich mich mit der Datenbank beschäftigen. Zumal es trivial ist.

Wenn Sie die Kontrolle über Ihren Datenbankserver haben: Benennen Sie die Tabelle core_config_data in core_config_data_offline um. Erstellen Sie eine neue Tabelle core_config_data mit der MEMORY-Speicher-Engine http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html Kopieren Sie alle Daten von core_config_data_offline nach core_config_data

Richten Sie einen Cron-Job ein, um zu überprüfen, ob core_config_data vorhanden ist, und ob alle Daten von dort nach core_config_data_offline kopiert werden. Wenn dies nicht der Fall ist, erstellen Sie es und kopieren Sie alles von core_config_data_offline nach core_config_data

Schalten Sie den Konfigurationscache aus. Wenn der Konfigurationscache aktiviert ist, erhalten Sie nur dann eine Leistungssteigerung, wenn Konfigurationsdaten zum ersten Mal aus der Datenbank gelesen werden. Danach befinden sie sich im Cache und Sie leiden darunter. Auf der anderen Seite werden die XML-Dateien nicht mehr zwischengespeichert, sodass Sie den Leistungstreffer beim Unserialisieren großer Konfigurationsdaten gegen den Leistungstreffer beim Parsen einer Reihe von XML-Dateien ausgetauscht haben.

Möglicherweise möchten Sie auch mit dem Ändern der Datei Mage / Core / Model / Config.php experimentieren und einzelne Website-Caches aktivieren. Standardmäßig werden alle speicherspezifischen Konfigurationsdaten einzeln zwischengespeichert. Alle Konfigurationsdaten der Website werden in einem Objekt zwischengespeichert.

Beachten Sie, dass dies nur für die Konfigurationsüberschreibungen [die Administratoreinstellungen] gilt. Wenn Sie also alle Konfigurationsänderungen auf Filialebene vornehmen, sind Sie bereits festgelegt. Wenn Sie "Von Website erben" verwenden und die meisten Änderungen in Ihrem Geschäft auf Websiteebene vornehmen, enthält der Cache jede Website. Durch Aufteilen können Sie es viel besser ausbrechen. protected $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'speichert' => 1, 'Websites' => 0);

zu

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
); 
Gary Mort
quelle
Hallo Gary, danke für diese hilfreiche Antwort! Ich habe einige Fragen: 1) Nach meiner Beobachtung ist die Datenbankabfrage selbst bei über 1.000 Websites / Geschäften kein Problem. Wenn dies der Fall ist, würde die Verwendung von Speicher noch helfen? 2) Ich weiß nicht, ob es korrekt ist, aber der Konfigurationscache scheint nur System- und Modulinformationen zu speichern. Hat das etwas mit der Konfiguration der Website / des Geschäfts zu tun? 3) Gibt es eine Möglichkeit für Magento, eine bestimmte Store- / Website-ID aus einer http-Anfrage zu erkennen und somit nur die entsprechende Konfigurationsdatei zu laden? Vielen Dank Gary!
Jack.W
2
Diese Empfehlungen befassen sich nicht mit dem Problem, das das OP festgestellt hat. Durch Deaktivieren des Konfigurationscaches wird das System letztendlich beendet. Dadurch wird Magento veranlasst, alle Konfigurationsdateien zu laden, sie zusammenzuführen, dann alle / global zusammenzuführen, dann alle / Websites zusammenzuführen und dann alles in jedem / store-Knoten zusammenzuführen. Das wird für JEDE Anfrage passieren. Bei 10.000 Websites können Sie pro Anfrage die Minuten der Wanduhr anzeigen .
Kevin Schroeder
Hey Kevin, danke für die Antwort; Eigentlich plane ich, die Tabelle core_config_data in den Speicher zu verschieben, den Cache für die System- und Modulkonfiguration zu aktivieren, zu verhindern, dass core_config_data in den Konfigurationsbaum eingefügt wird, und Funktionen zu erstellen, die diesen Teil der Daten direkt aus der Datenbank abfragen. Was denken Sie?
Jack.W
1
Das Problem ist nicht core_config_data. Das Problem ist, dass Speicherkonfigurationen von / Websites zusammengeführt werden, die von / global in XML zusammengeführt werden. Die Datenbank ist vollkommen in Ordnung. Es ist PHP, das aufgrund der Zusammenführung der Konfiguration das Leben hassen wird. In Ihrem Debugger-Schritt durch Mage_Core_Model_Resource_Config :: loadToXml achten Sie besonders auf die Zeilen 110 und folgende
Kevin Schroeder
1
Kommen wir nun zu meiner Speichertabelle zurück. Das Zwischenspeichern von Daten bedeutet, dass sie an einem Ort gespeichert werden, auf den schnell zugegriffen werden kann. Magento speichert Konfigurationsdaten in einem PHP-serialisierten Objekt zwischen. Wenn Ihre Konfigurationsdaten sehr groß sind, muss PHP für jede Anforderung eine große Datenmenge deserialisieren. Wenn Sie wissen, wie man xdebug verwendet, profilieren Sie einige Ihrer langsameren Seitenladevorgänge und sehen Sie sich an, wie viel Zeit für die Ausführung der unserialize-Funktion aufgewendet wird: php.net/manual/en/function.unserialize.php - wenn es riesig ist [über 100 ms], dann Durch "Caching" der Konfiguration wird Ihr System beschädigt.
Gary Mort