現在、英国ではWebサーバーからの最初の応答が200ミリ秒未満である必要があるという要件に取り組んでいます。現在、ロードバランサーの下にある2つの専用Webサーバーと1つのdbサーバーの下で、800ミリ秒で到達しています。

現時点では、サイトの顧客数は5、製品数は2、カテゴリ数は4未満であり、現時点ではサイトのフロントエンドはなく、スタイルもイメージも無料です。

また、Varnishを使用してnginxで実行されています。

誰も私にウェブサーバーのセットアップに関するアドバイスをくれますか？なぜ私たちのものがゆっくり入ってくるのですか？これを最適化するために何をお勧めできますか？400％速くなる必要があります！

噛みます。

Webサーバーからの最初の応答は、英国では200ミリ秒未満である必要が
あります。現時点では、サイトへのフロントエンドはありません。スタイルもイメージもありません。

VarnishまたはFPC（あるいはその両方）の助けがなければ、これらの数値を達成することはできません。私は確かに、（あなたがそれを追加することに決めたときはいつでも）静的コンテンツを含める必要がないことを望みます-達成することはほぼ不可能であるため（images / js / cssがほとんどまたはまったくない）。

私たちは800msで来ています。
それは、ワニスと一緒 にNginxでも実行されています。

Varnishの設定が間違っています。

Varnishのインストールを適切に構成すると、ページの読み込み時間が100ミリ秒未満になります（10ミリ秒近くになります）。

実際、Magentoの場合、このようなものが表示されることを期待してください。

顧客がログインしていないとき...
すなわち。一意のセッションを作成していない（カート/ウィッシュリストに追加、ログインなど）

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

顧客がで...ログインしている場合は
すなわち。一意のセッション（ログイン、カート内のアイテムなど）を作成した。この時点で、ニスはオフになりそうです。また、ESIを使用することを選択した場合（リバースコールに応じて、FPCキャッシュと同様のページ読み込み時間を維持できます（ブートストラップのオーバーヘッドにより））、または実際にページの読み込み時間をキャッシュ解除よりも長くします。

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Varnishをチューニングする場合ではなく、「実際には何もキャッシュしていない」場合です。

理想的なMagentoサーバー構成ファイル

まったくありませんが、まったくありません。

さまざまなサイズと容量の400を超えるサーバー（すべてMagentoストア）を運用しています。そして、あるファイルにある設定ファイルが他のファイルと一致することはまれです。それは、すべての企業が同じではないためです。

ボトルネックは、さまざまな理由で発生する可能性があります。

1. 多数の訪問者の同時実行、アクティブなセッション
2. 「悪い」クロールボットの犠牲者、必要な貴重な負荷を生成
3. 階層化されたナビゲーションヒットの割合が高い
4. 多数の検索クエリ
5. 1時間あたりの大量のトランザクション
6. 貧弱に構築されたテンプレート
7. サードパーティの拡張機能が多すぎる/遅い/かさばる
8. 古くなったインバウンドリンクが404ヒットの割合が高い
9. ネットワークインターフェイスの容量が制限されています
10. 大規模/複雑なカタログ（製品/カテゴリ/属性のロット）

そのため、このスペクトル全体の店舗では、それぞれが最適なパフォーマンスを実現するための異なるアプローチを採用しています。

上記の問題を解決するには。「より良い/より良いハードウェア」と述べることを意図的に避けます。

1. ワニスを超えたFPCを使用する
2. ネットワークエッジでの不正なボットのフィルタリング/ブロック-またはCookieの状態/ URLに関係なく、すべてのリクエストをVarnishにリダイレクト
3. ストックレイヤーナビゲーションをSOLRに変更し、レイヤーナビゲーションフィルターを依存させる
4. 在庫検索をSOLRに変更
5. MySQLの負荷をマスター/スレーブ構成全体に分散します-これは、閲覧負荷がVarnish / FPCによって吸収されることが保証されている場合にのみ行います
6. テンプレートを再構築する
7. それらを取り除きます
8. アクセスログを継続的に監視し、配信前にNginx / VarnishでURLを書き換えます。Nginxレベルで実行する場合-Varnishが301/302リダイレクトをキャッシュしていることを確認してください。
9. 静的コンテンツをCDNに分割するか、接続を改善します
10. ハードウェアを追加します（まあ、ある時点でそれを言わなければなりませんでした）

したがって、これを念頭に置いて、同じNginx構成ファイル、PHP fcgiプール構成ファイル、MySQL構成ファイル、またはVarnish構成ファイルが存在することはおそらくないでしょう。それをハードウェアの変更自体と組み合わせてください。使用可能なメモリ、I / Oパフォーマンス（HDDおよびネットワーク）、CPU-微妙なバリエーションがあり、希望する400％のパフォーマンス向上につながりますが、オンラインで簡単に答えられるものはありません。

Peer 1がスポンサーしたMagentoのパフォーマンスに関するホワイトペーパーをコピーして貼り付けることができます（お勧めしません）。設定が利用可能なメモリ、スレッド制限、TCP / IP状態、I / O容量を超えないようにし、通常のApache / mod_php構成よりもパフォーマンスが低下することを願っています。

続けましょう。

理想的なMagentoサーバースタック

これにより、より現実に近づくことができます。これを実証する良い例は、専用のMagento OSがどのように構成されているかを示すことです。MageStack

個別のサブコンポーネントを使用すると、Magentoストアを実行するために適切に構成された場合に最も最適/重要なソフトウェアのリストが得られます。特に：

ファイアウォール、DOSフィルター、ロードバランサー、ワニス、Nginx、PHP、Redis、Memcached、MySQL

あなたが尋ねるとき：

最高のMagento Serverセットアップとは何ですか？

正確にあなたの目標は何ですか？

1. 高可用性
2. 信頼性
3. 管理のシンプルさ
4. 性能
5. 拡張性

十分な講義、それをどうするか

サーバー障害に関する回答を部分的にミラーリングするには、同様の方法で行います。3台のサーバーを自由に使用できます。最初に可能な限り最適な方向に向けてください。高可用性ソリューションはこの回答の範囲をはるかに超えているため、回避します。

マルチサーバー構成に必要なサブコンポーネントは次のとおりです。

• ファイアウォール
• ロードバランサー
• Webサーバー
• MySQLサーバー
• 共通ストレージ

そこで、いくつかのシステムを多目的にします。PCI-DSS準拠により、各サーバーの役割が決まります。したがって、5つのロールと3つのサーバーを使用すると、すぐに侵害されます。MageStackは、仮想化を使用してこれを回避します。同じことを行うこともできます。

サーバー1：ロードバランサー+ Webサーバー
サーバー2：Webサーバー
サーバー3：データベースサーバー

低レイテンシーおよび大きなネットワーク帯域幅（> 1Gbps、<125µs）なしで、共通のストレージを使用するのではなく、各マシンにストアルートディレクトリを保存し、リアルタイムで使用ionotifyまたは経過したデータを複製する方が良いcron仕事。繰り返しますが、NFSのようなネットワークファイルシステム、またはGlusterやDRBDのような複製されたブロックデバイスは、大規模な調整と適切なネットワーク帯域幅が必要なため、避けます。

ワニスは、できる限り正面に近づけて座る必要があります。ただし、ワニスはSSLを解読できません。SSLターミネーターと組み合わせてください。Nginx、Pound、Stunnel、Studなど。Varnishに組み込まれているロードバランサーは素晴らしいものではありませんが、2台のサーバーをセットアップするには十分でしょう。

Nginx + PHP-FPMは問題ありませんが、Nginxのクールエイドを飲みすぎないでください。これは、従来のApache / mod_php構成とほぼ同じように動作します。ここでは、なぜNginxを使用しないのかについての良い読み物があります。Nginxは優れた、非常に優れた事実ですが、Magentoストアのボトルネックではありません。複雑さとネイティブのMagentoサポートがないためです。ほとんどの初心者のシステム管理者は、Apache / mod_phpを他の何よりも使用することで恩恵を受けるでしょう。これはPHP-FPMを使用するよりも古くからの推奨事項のように思えますが、パフォーマンステストでは、適切に構成されている場合、Nginxソリューションを使用した場合のパフォーマンスは最大で7％しか向上しませんでした。高性能で信頼性の高いNginx / PHP-FPMのセットアップに必要なチューニングと経験は、Apache / mod_phpをアウトパフォームするためにはかなり膨大です。どちらを使用するかは、あなたの電話です。

データベースサーバーはシンプルなMySQLです。ただし、前述のように、コンバージョン率の高いサイトがある場合は、マスター/スレーブ構成をお勧めします。このアプローチに従うべきかどうかは、この記事を読むことで判断できます。

次に、周辺機器のバックエンドキャッシュであるMemcachedとRedis。小規模なストアでは、セッションを1つのMemcacheインスタンスに保存し、高速バックエンドキャッシュを別のインスタンスに保存すると、パフォーマンスが向上します。キャッシュタグを遅いバックエンドに保存することは推奨しません-それが与えるよりも多くの問題を引き起こすからです。したがって、Memcachedのセットアップでは、キャッシュのタグ付けを放棄する必要があります。代わりに、このような構成を使用します。

RedisはMagentoのネイティブではありませんが、Colin Mollenhourの拡張機能（Memcacheよりも優れたソリューション）により、キャッシュタグ、セッションストレージ、さらには永続キャッシュストレージまでサポートされ、Memcacheほど揮発性ではありません。ただし、欠点もあります。私たちは、上で見つけた大規模な（キャッシュ（とタグ）という（30Kユニーク/時間>、> 500回の注文/時間）を生産店は非常に迅速に埋めることができ、彩度のポイントがヒットされた後、LRUメカニズムは、多少失敗しますさまざまな設定にもかかわらず）、すぐに大きなボトルネックを引き起こします。そのため、古いレコードを定期的に手動で整理するのが賢明です。

それで、何のためにどんなハードウェアを使うべきでしょうか？

Webサーバー：最も高速なCPU、ほとんどのCPUコア、2GB RAM /コア
DBサーバーの比率：高速なCPU、最も高速なディスクI / O、ほとんどのRAM

したがって、3台のマシンを多目的に使用する場合、最適なレイアウトは次のとおりです。

サーバー1：SSLターミネーター->ワニス-> Nginx / Apache> PHP
サーバー2：Nginx / Apache> PHP、Redis、（MySQLスレーブ）
サーバー3：MySQL

各アプリケーションの特定の構成について。それは、ハードウェアの仕様、店舗の複雑さ、訪問者のタイプと性質、そして訪問者の膨大な量にかかっています。

そのクラスター構成で素晴らしい道を歩んでいます。Redis専用のキャッシュホストを追加することをお勧めします。高いCPUパワーと大量のRAM（〜64 GB）を選択してください。

高可用性、フォールトトレラント、分散、および負荷分散されたLEMPクラスターに使用した構成の完全なリストを以下に示します。これにはapp/etc/local.xml、core_config_dataMySQL、php-fpm、nginx、およびRedis の表、構成が含まれます。すべてがUbuntu 12.04 LTS 64ビットを実行します。構成には、欠点のない多くの最適化が含まれています。

ハイライト

• 管理ユーザー：46
• カテゴリ：2,450（最大のものには2,400の製品があります）
• 製品エンティティ：101,000
• コンボ製品：484
• 製品関係：54,000
• 在庫および有効な構成可能製品：10,100
• CMSブロック：3,100
• CMSページ：1,400

2013年8月のトラフィック：

• 月間4000万ページビュー
• 230万のユニークビジター
• 46,000の毎月のチェックアウト
• アメリカからの訪問者の89％

Webホスト

冗長性のある高可用性ハードウェアファイアウォールとハードウェアロードバランサーの背後には10個のホストがあります。ほとんどの静的アセットはCDNにオフロードされます。

• サイト全体の平均応答時間：282ミリ秒
• 平均FPC応答：48ミリ秒
• 負荷平均：0.6〜1.0（テストでは、負荷平均が〜5.0に達するとパフォーマンスが35％低下します）
• デュアルIntel Xeon CPU E3-1230 V2 @ 3.30GHz（各4コア）
• 32 GB DDR3 1333 MHz RAM

モジュール

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = models
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = production
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

キャッシュホスト

自動フェイルオーバーを備えたマスター/スレーブ構成でRedisを実行している2つのホストがあります。3つのRedisインスタンス（セッション、バックエンド、およびFPC）を使用して、スループットを向上させ、永続性の動作を微調整します。

• 1秒あたり3,000コマンド
• 平均応答時間0.7 ms
• 1.0から1.5の平均負荷
• クアッドIntel Xeon CPU E5-2620 0 @ 2.00GHz（各6コア）
• 128 GBバッファー付きDDR3 1333 MHz RAM
• メカニカルディスク、RAID 1、ハードウェアコントローラー

データベースホスト

ウォームフェールオーバーを備えたマスタースレーブ構成でMySQL 5.6.11を実行している2つのホストがあります。

• 1秒あたり1,500コマンド
• 1.1ミリ秒の平均応答時間
• 0.1（マスター）と0.4（スレーブ）の平均負荷
• クアッドIntel Xeon CPU E7-2860 @ 2.27GHz（各10コア）
• 128 GBバッファー付きDDR3 1333 MHz RAM
• SSD、RAID 1 + 0、ハードウェアコントローラー
• tcmallocを使用したMySQL 5.6.11

別のMagentoのサーバーヒントは、PHP 5.4または5.5をOPcacheとともにインストールすることです。PHP 5.4は5.3よりもずっと高速です（http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/）。

ワニスでキャッシュされておらず、デフォルトで有効になっていない場合（カートページの読み込み時間が6scから1.5scに変更されたとき）にmagentoページの速度を改善する別の重要なヒントを追加します。

/etc/mysql/my.confのmysqlクエリキャッシュをアクティブにします

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_typeで有効にします。キャッシュサイズはメモリ内のキャッシュで使用される値で、キャッシュ制限はキャッシュするクエリ結果の最大サイズです

現在の構成では、400ミリ秒で初期応答を受信し、2秒でドキュメントを完了します（5 mbpsの標準接続を使用）。ホームページのサイズは1MBです。

次のように、セットアップはAWSに基づいています：RDSデータベースに接続されたロードバランサーを備えたec2インスタンスがあります（フェールオーバーあり）。また、キャッシュストレージとセッションストレージの両方にRedisキャッシュバックエンドを使用したフルページキャッシュを実装しました。

1日平均300〜400人の訪問者がいますが、redisキャッシングを有効にすると、速度を維持しながらコストを削減しながら、ec2リソースの使用量を最小限に抑えることができました。

ロードバランサーを使用する理由は、現在の設定では処理できないトラフィックスパイクがまれに発生した場合に、ec2が新しいインスタンスを自動的に起動するように設定されているためです。