1000〜10,000のWebサイト/ストアのパフォーマンスの問題

Webサイト/ストアの数が1kを超え、私の目標が約10kである場合、Magentoのパフォーマンスを改善する方法を見つけようとしています。ここにいくつかの質問があります。ヒント/ヘルプは大歓迎です！

1. 新しいWebサイト/ストアの追加には時間がかかります。
   Mage_Core_Model_Abstractの_afterSave（）の$ this-> cleanModelCache（）をコメントアウトしました。状況は改善されたように見えますが、Webサイト/ストアの数が増えるにつれて遅くなっています。そして、これが将来システム全体にどのような影響を与えるかわかりません。

2. API呼び出しが遅くなります。
   主なプロセスの1つは注文を出すことです。私のカスタマイズしたモデルは、一部のデータを処理し、基本的にはsales / quoteモデルとsales / service_quoteモデルを使用して処理します。プロセスはOauthから始まります。ウェブサイト/ストアの数が増えると、Oauthと注文の両方に時間がかかり、メモリ消費量が大きくなります。これはMageがconfig xmlをロードすることと関係がありますか、そしてwebサイトの数が増えるとconfigデータが大きくなるという事実はありますか？

3. n98-magerun dev：consoleを開くのに時間がかかります。その原因はわかりません。

4. 管理パネルから設定を保存すると時間がかかります。それを改善する方法がわからない。

Magentoが構成データを生成してロードする方法を再構築して、メモリ消費量を減らすことは可能ですか？これは、私の状況でパフォーマンスの問題を引き起こす要因の1つですか？

現在のMagentoインスタンス：バージョン= Magento EE 1.14.2.4;
設定キャッシュがオンです。他のキャッシュオフ;
Mysql 5.6とMongoDBを使用する（catalog_category_entity、catalog_product_entity、core_websiteの場合）;
ウェブサイトの数=店舗の数=ビューの数= 1024;
製品数= 4501;

よろしくお願いします！

遅くなる理由の1つは、各ストアの構成が/ config / websitesおよび/ config / globalから複製され、それを行うためのコードが少なくとも効率的でないためです。設定を変更すると、パフォーマンスとスループットが低下する場合があります。それをより効率的にすることは、基本的にベン・マークスがあなたの後に来ることを意味します...そして、良い方法ではありません。

このルートを使用する場合、最も簡単な方法は、1万のMagentoをインストールし、適切なWebサイトにリクエストを委任するブローカーのようなものを用意することです。もちろん、実際の使用例によって異なります。

【追加】

ユースケースによっては、カテゴリーを疑似ストアとして使用できる場合があります。技術的には、レイアウトXMLを使用して店舗ごとのテーマを変更できます。しかし、チェックアウトの制限にぶつかります。すべての店舗がチェックアウトを共有する必要があります。

いずれにせよ、Magentoの10kストアは不可能ではありません。しかし、それはあなたがどんな道を選んでも難しい道になるでしょう。

コアをハックしてWebサイトのキャッシュ分割を有効にしてみてください。データベースをハッキングして構成情報をメモリに保存してみることができます。オーバーライドデータを動的に取得しながら、構成キャッシュをよりスマートなものに置き換えてみてください。たとえば、xmlファイルからの情報をキャッシュするとします（静的であり、すべてのWebサイトとストアに適用されます）。

私はサーバーの男なので、データベースをいじくり回します。特にそうするのは簡単です。

データベースサーバーを制御できる場合：core_config_dataテーブルの名前をcore_config_data_offlineに変更しますMEMORYストレージエンジンを使用して新しいcore_config_dataテーブルを作成します http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html すべてのデータをcore_config_data_offlineからcore_config_dataにコピーします

cronジョブをセットアップして、core_config_dataが存在するかどうかを確認し、そこからすべてのデータをcore_config_data_offlineにコピーするかどうかを確認します。含まれていない場合は、作成して、core_config_data_offlineからcore_config_dataにすべてをコピーします。

設定キャッシュをオフにします。構成キャッシュをオンにすると、構成データがデータベースから初めて読み取られたときにのみパフォーマンスが向上します。その後、キャッシュに格納されて問題が発生します。欠点として、xmlファイルはキャッシュされなくなったため、大量の構成データをシリアル化解除するパフォーマンスヒットと、一連のxmlファイルを解析するパフォーマンスヒットを交換しました。

また、Mage / Core / Model / Config.phpファイルを変更して実験し、個々のWebサイトのキャッシュを有効にすることもできます。デフォルトでは、各ストア固有の構成データは個別にキャッシュされます。すべてのWebサイト構成データは1つのオブジェクトにキャッシュされます。

これは、構成の上書き[管理者設定]のためだけのものであることに注意してください。したがって、ストアレベルですべての構成変更を行う場合は、既に設定されています。「ウェブサイトから継承」を使用し、ストア固有の設定変更のほとんどをサイトレベルで行う場合、キャッシュにはすべてのウェブサイトが含まれます。それを分割することで、あなたはそれをよりよく分解することができます。保護された$ _cacheSections = array（ 'admin' => 0、 'adminhtml' => 0、 'crontab' => 0、 'install' => 0、 'stores' => 1、 'websites' => 0）;

に

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
);