あなたはここで幅広い最適化の世界に入り込んでおり、すべてのアプローチに適合するサイズではありません。
パフォーマンスを定義する
単一のユーザーのページ読み込み時間ですか、それとも全体の容量/合計同時実行数ですか？この2つは非常に明確に異なり、厳密には関連していません。容量が制限された高速ストアを使用することは完全に可能です。または、容量の多い低速ストア。
したがって、いずれかのタイプのパフォーマンスに対処する場合：
- 単一のユーザーが認識するページのロード時間
- 総容量/同時実行
特に、それぞれに独自のボトルネックがあるため、独自のソリューションでそれぞれに個別に取り組む必要があります。
あなたがあなたの店に最適なサーバーの他の側面をすでに設定している有能なホストを持っていると仮定しましょう。
単一のユーザーが認識するページのロード時間
MySQLはボトルネック
です。直接ではありません。ほとんどすべての場合、ページの読み込み時間をテストするときに、キャッシュのみがヒットします。したがって、ここで重要なのはレイテンシーを最小限に抑えることです。
- MySQLのキャッシュサイズを適切 に調整します（正しい答えはありません。ストアごとに毎月、まったく異なる設定を調整します）
- ネットワークの待ち時間を短縮します。64バイトフレームの場合。10Mbpsで51.2µs、100Mbpsで5.12µs、1Gbpsで4.096µs。これにより、100Mbpsから1Gbpsに移行するだけで20％の改善が得られます。s1
- ネットワーク容量を増やします。WebサーバーとDBサーバーの間では、通常10MB / sを超える数メガバイト/秒のデータ交換が行われることに驚かれることでしょう。そのため、最低100Mb / sが必要ですs1。または、DBサーバーをローカルに移動するだけです。
- SOLRを使用します。外部エンジンの方が適している場合もありますが、SOLRは確かに大きいカタログの方が高速です（そして、カタログが大きいほど強調します）。チューニングされていないSOLRでさえ、MySQLよりも速く階層化されたナビゲーションと検索結果を生成します。
しかし、これらの変更は、ページのロード時間にこのようなわずかな影響を及ぼします-ボトルネックは本当に他の場所にあります。
- アプリケーションを調整します。Magentoには、コレクションを構築してキャッシュする方法にかなり大きなバグがあります。パフォーマンスを損なう可能性のあるいくつかの大きなコアコードの問題に遭遇しました。いくつかのケースでは、階層化されたナビゲーション結果の製品カウント表示を削除するだけで、大きなコレクションの読み込みに2 秒かかりました。
- MySQLスローログを確認します。遅いクエリを確認し、必要に応じてインデックスを追加します。適切なインデックスがある場合とない場合の複数の結合で複雑なクエリを実行する場合の違いは、数十秒になることがあります。
アプリケーションがボトルネックです。ソフトウェアではありません。だから、単にコアコードを改善したり、テンプレート以下の重を作ることよりもパフォーマンスにはるかに劇的な効果がありますANY MySQLの設定変更を。
私たちは何を気にしませんか
- ストレージエンジンの変更。MariaDBとPerconaは同じInnoDBエンジン-Percona XtraDBを共有しています。それらは同一のものとして扱うことができます。単一クエリの実行時間に関しては、パフォーマンスはバニラMySQLビルドを正確に反映します。これは、負荷/並行性の下で機能します。
- MySQLスレーブの実行。これは、スレーブが（ネットワークの観点から）物理的に近くに配置されていない場合、またはスレーブがマスターよりも優れたハードウェアを持っている場合を除き、パフォーマンスを改善しません。これは、負荷/並行性の下で機能します。
- 外部DBサーバーの実行。これは、多くのホスト/代理店から繰り返し配布されている最悪のアドバイスです。ハードウェア/リソースの上限に達するか、複数のWebサーバー（高可用性）を入手するまで、Magentoストアのローカルマシン上のMySQLは良いアイデアです。すべてのネットワークオーバーヘッドと遅延を削減します。100Gb / sネットワーク（はい、1秒あたり100ギガビット）でさえ、rawボリューム、スループット、およびレイテンシーについてはローカルUNIXソケットとは比較されません。
s1個別のデータベースサーバーのみ。ローカルDBサーバーには適用されません。
総容量/同時実行
MySQLがボトルネック
かもしれません。ただし、PHPのパフォーマンスと容量をMySQLの速度が低下する程度にまで抑えた場合に限ります。VarnishとFPCが適切に構成されている場合 （どちらでも失敗した試行回数を開始しないでください） -MySQLはボトルネックになります。
したがって、上記の変更に加えて。
- MySQLエンジンを変更します。XtraDBは負荷がかかった状態でも優れており、在庫のMySQLディストリビューションに比べて真の利点を示しています。
- MySQLの最新情報を入手してください。5.5は、負荷がかかった状態で5.0よりも優れたパフォーマンスを示します。
- PHP MySQLドライバーを変更します。PHP 5.3以降にはネイティブのMySQLドライバーがありますが、状況によっては、PHP 5.2がMagentoのMySQLNDよりも優れた別個のドライバーを備えていることがわかりました。自分でテストする
- 検索エンジンを変更します。検索をSOLR / Sphinx（またはサードパーティの外部サービス）に移動すると、非トランザクション負荷（つまり、注文しない人）の負荷を本当に軽減できます。
- 階層化されたナビゲーションエンジンを変更します。繰り返しになりますが、SOLRは階層化されたナビゲーション用の優れたエンジンであり、その非ロック性によりMySQLよりもはるかに高速です。
- MySQLスレーブを追加します。これはブラウジング（非トランザクション）負荷の助けにはなりますが、このデータの処理と複製はマスターに依存しているため、1時間あたりの注文数の処理には役立ちません。
私たちは何を気にしませんか
- マスター/マスター。マスター/スレーブ設定のハードウェア飽和の非常に高い転換点（1時間あたり1000オーダーを超える）により、マスター/マスターを実稼働で使用するための要件を見つけることができませんでした。広範なテストを実施しましたが、パフォーマンスの観点からメリットがあることは一度もありませんでした。マスター/マスターに固有のリスクと問題があるため、それだけの価値はありません。
読み取りと書き込みのスケーラビリティ
最後の段落は、読み取りおよび書き込みのスケーラビリティの重要な領域につながります。読み取りスケーリングは、より多くのスレーブを追加することであまり複雑にすることなく、かなり無限に実行できます。
書き込みに対する読み取りのMagentoの比率が約0.1％であることを考えると、書き込みを考慮する必要はあまりないはずです。そのため、MySQL Clusterと、自動シャーディング（テーブルを別のマシンに分割する）のような巧妙な機能について言及する必要はありません。
ハードウェア、ハードウェア、ハードウェア
ハードウェアは、改善に関しては最も簡単な答えであるため、どちらのシナリオでも意図的には言及していません。
しかし、基礎となるハードウェアが不十分な場合、世界のすべてのソフトウェアの変更は何の違いももたらさないでしょう。つまり...
- バッファが制限された低品質のスイッチ
- 過度に飽和したネットワークリンク
- 地理的に離れたサーバー
- 悪いネットワークQoS / CoS
- 限られた合計RAM
- 低メモリ帯域幅RAM
- 低IOP HDDサブシステム
- ソフトウェアRAIDコントローラー
- 低クロック速度のCPU
- 低帯域幅のチップセット
- ハードウェア仮想化（カーネルレベル仮想化を除くほとんどすべてのタイプ）
最近では、ハードウェアで実際にどれだけ拡張できるかについて、非常に高い天井があります。クラウドハードウェアはかなり平凡な傾向があるため、「クラウド内」の無限スケーリングの神話を無視しましょう。たとえば、Amazonのフラッグシップモデルは3.3 GHzで12コアのみです。しかし、これ以外にも非常に強力なサーバーがいくつかあります。トップサーバーには160コアと2TB（はい、テラバイト）のRAMがあります。まだその能力を超える人はいません。
そのため、水平方向のスケーリングを検討する必要が生じる前に、垂直方向のスケーリングの大規模なスコープがあります。
常に動いているターゲット
パフォーマンスを追求する上で、ボトルネックは常に動き続けることを言及する価値があります。
在庫Magentoストアの場合。
キャッシュをオンにします。PHPがボトルネック
バックエンドキャッシュを追加します。PHPがボトルネック
ですアプリケーションレベルのフルページキャッシュを追加します。PHPがボトルネック
サーバーレベルのフロントエンドキャッシュ（例：Varnish）を追加します。MySQLがボトルネック
代替の検索/階層化ナビゲーションエンジン（SOLR / Sphinxなど）を追加します。PHPがボトルネック
ですアプリケーションサーバーを追加します。MySQLがボトルネック
MySQLスレーブを追加します。フロントエンドキャッシュがボトルネックです
フロントエンドキャッシュサーバーを追加します。PHPがボトルネック
ですアプリケーションサーバーを追加します。SOLR / Sphinxはボトルネックです
等。
それはすすぎ洗いリピートのケースになります。しかし、理解しやすいのは、MySQLが最適化の最初の呼び出しポートではないこと、そしてMySQLがPHPに比例してCPUをより多く消費している場合にのみ実際に作用することです。また、サーバーは純粋に注文を処理しており、他には何もありません（他のすべてがキャッシュにあるため）。
盲目的に変更しないでください
MySQLスレーブを追加するだけで、それが役立つと上記の説明を読んだため、パフォーマンスと信頼性が大幅に低下する可能性があります。混雑したネットワーク、低スペックのスレーブサーバー、または不適切な設定によって、レプリケーションの問題が発生し、ストアが当初よりも遅くなったり、マスターとスレーブ間の同期の問題が発生したりする可能性があります。
物事を視野に入れるために-いくつかの現実世界の例。
例1-1時間あたり300件の注文
次のハードウェアを使用して、1時間あたり300件の注文を処理しました。そしてその転換点でのみ-専用のMySQLサーバーとローカルのMySQLスレーブを追加する必要性を感じました。
1サーバー
CPU：2x Intel E5-4620
RAM：64GB HDD：4x 80k IOP / s SSD
RAID：ハードウェアRAID 10
Magentoバージョン：Magento EE
OS：MageStack
全体を通して、負荷平均は3.00未満のままでした。
例2-1時間あたり180件の注文
わずか2日前、私たちの新しいクライアントは簡単に大きなトラフィックスパイクを吸収しました。単一サーバーとMagento Community Editionで 1時間あたり180件の注文を処理します。
1サーバー
CPU：2x Intel E5-4620
RAM：64GB HDD：4x 80k IOP / s SSD
RAID：ハードウェアRAID 10
Magentoバージョン：Magento CE
OS：MageStack
ウェブサイト：Wellgosh.com
全体を通して、負荷平均は6.00未満でした。このシナリオでは負荷が高く、それはいくつかの要因にかかっていました。
- 例1のようなストア側のチューニングは実行されませんでした
- アプリケーションレベルのFPCの欠如
そして、この最新性を考えると、グラフを使用してフィードバックを提供するための詳細な統計がまだあります。これらは、分離されたMagentoアーキテクチャの重要なコンポーネント（ロードバランサー、Webサーバー、DBサーバーなど-MageStackを使用）の間で負荷がどのように分散されるかについての素晴らしいストーリーを伝えます。
そのため、前から後ろへ...見たい日付は2月22日の午前12:00です。
ファイアウォールパケット
ニストラフィック
Nginxトラフィック
MySQLロード
CPU負荷
そして最も重要なことは、負荷の分散
この画像は本当にすべてを物語っています。そして、MySQLは確かに負担ではありません - 少なくともまだです。したがって、1時間あたり数千件以上の注文を処理している場合を除き、パフォーマンスの懸念を他の場所に集中させてください。
そして要約すると
パフォーマンスを変更することは、「1つのサイズですべてに適合する」ということではありません。これは、現在のボトルネックを分析し、店舗やインフラストラクチャに合わせて微妙な変更/調整を行う場合です。
ただし、パフォーマンスは別として、Perconaを使用することには他の利点もあります
ほぼ独占的にPercona XtraDBを使用しています。私たちは、Magento用に特別に開発し、プロセス中にPerconaに相談したMySQLのカスタムコンパイルビルドを実行します。しかし、この選択に影響を与えたのはパフォーマンスだけではありません。
- Perconaツールキット
- pt-query-digest
- xtrabackup
- 等
- パーコナのリリース頻度
- Perconaのコンサルティングサポート
- InnoDBプールの保存でウォームキャッシュが再起動する
そして、はるかに。したがって、MySQL上で使用することには、パフォーマンス以外の利点もありました。実際、パフォーマンスと安定性を追求する上で、MySQLは私たちの懸念事項であり、これまでもそうでした。
属性：wellgosh.com、sonassi.com、iebmedia.com。