Leistungsproblem mit 1k bis 10k Websites / Stores

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!

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.

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
);