序文の代わりに
この記事は、Drupalの公式Webサイトで入手可能なサーバーのチューニングに関する考慮事項に基づいています 。 それから、選択されたものは本質的に最も普遍的であり、Drupalが使用される予定の任意のサーバーに適用できます（特に、PHPとMySQLのセットアップに関するセクション）。 この記事では、CMS自体の微調整については説明しません。
実験モデル
負荷を確認するために、特定の参照の重いサイトが作成されました。 このために、Drupal 7と、ViewsやPathautoを含むいくつかの一般的なモジュールが使用されました。 1〜10の値を取ることができる数値フィールドが材料タイプの1つに追加されました。Develモジュールのコンテンツ生成機能を使用して、約1万ページのこのタイプの材料が作成されました。
次に、Viewsブロックが作成され、メインページに配置され、100ページのランダムページを選択しました。フィールドの値は5（つまり、確率論によれば、1000ページ中100ページ）とコメントが含まれていました。 グローバル：ランダムフィルタリング基準を使用して、ロードのたびにページが新たに生成されることを保証しました。 個人用テストサーバーでは、このようなページの生成時間は約10秒でした。 また、準備中に、Commerce Kickstarterに基づくテストオンラインストアが作成され、約5,000の製品が生成されました。 ただし、グローバル：ランダムはSearch APIとまったく友好的ではなく、ランダム化を行わないと、96個の製品を含むページが以前のテストページよりも大幅に高速に読み込まれました。 したがって、オンラインストアの速度の測定は実行されませんでした。 テストサイトが移動されました...
実験装置
実験のために、私は数日間、新しくインストールしたVPS Intel Xeon E3-1230 3.2GHz / 2-3 GB RAM / 30 GB SSDとIntel Xeon E3-1230 / 8GB DDR3 / 4x1TB SATA2 / 100Mbps Unmeteredをオランダで借りました（以下、VPSと呼びます） E3-1230、それぞれ）。 サーバーには、標準のLAMP + Nginxが構成されていました。 ほとんどの測定は、合計リクエスト数1000および並列リクエスト数10〜50でabユーティリティによって実行されました。最後に、いくつかのLoadimpactテストも実行されました。
生サーバーデータ
最初の測定は、最適化が始まる前に行われました。 実際、これらの測定では、40の並列クエリで解決しました。 得られた結果は次のようになります。
X軸に沿ったこのグラフおよび後続の同様のグラフでは、Y軸に沿った対応する値を超えない期間に処理されたリクエストの割合があります。
さらに、興味のために、無料のLoadimpactテストを開始しましたが、実際の負荷は発生しませんでした。
PHPの最適化
Drupalの下のサーバーで最初に行うことは、php.iniでmemory_limit値を少なくとも256Mに設定することです。 原則として、これはほとんどのサイトで完全に十分です。 ただし、128Mでは十分でない場合があります。 ただし、これは最適化と呼ぶことはできませんが、それはかなり重要な必要性です。
PHPレベルでサイトの作業を高速化するために、開発者はさまざまなキャッシングオプティマイザーの使用を推奨しています。 他の情報源はしばしばAPCに言及しているので、私は彼に頼りました。 あなたはそれを指示に入れる方法について読むことができます。 ここで重要な設定に興味があります。 実際、メインパラメータはキャッシュメモリセグメントのサイズapc.shm_sizeです。 ページが重いほど、実行時に含まれるファイルが多くなるほど、値は大きくなります。 たとえば、テストサイトには64Mで十分でした。 この値を持つテストストアはエラーを生成しました。
[Mon Jan 13 21:41:46 2014] [error] [client 176.36.31.190] PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0, referer: http://s2shop.1b1.info/products?page=2
値を256Mに上げると、この問題はすぐに解消されました。 Develモジュールによると、サイトを1回だけ表示すると、キャッシングを含めると次のパラメーターに影響がありました。
- ページ生成時間は1.5倍から2倍に短縮されました。
- ピークメモリ消費量は、テストサイトでは約50〜55 MBから30〜32 MBに、テストストアでは約65〜70 MBから30〜32 MBに減少しました。
APCの包含がabによる爆撃の結果にどのように影響したかについては、少し後で説明します。 公開されている公開情報によると、Apache + mod_phpの代わりにphp-fpmを使用すると、驚くべき結果が得られます。 ただし、これら2つの構成をまだ比較しようとはしていません。
MySQLの最適化
MySQLを最適化する最も簡単な方法の1つは、my.cnfをmy-huge.cnfに置き換えることです。 このファイルは、十分な（2 GB以上の）RAMと大規模なMySQLの使用を備えたシステム用に設計されています。 とりわけ、バッファサイズ（key_buffer_size）が大幅に大きく、クエリキャッシング（query_cache_size）が含まれている点で、標準の構成とは異なります。
連続使用中の反動速度の一般的な変化は次のようになります。
E3-1230、10個の並列リクエスト
VPS、10同時リクエスト
E3-1230、30の並列リクエスト
VPS、30の同時リクエスト
ご覧のとおり、VPSでは、最適化されていないMySQLと最適化されたものの間のギャップは、E3-1230よりも顕著です。 これは、VPSでSSDドライブを使用していることが原因だと思います。 今日、データベースがSSDに配置されているサーバー構成がますます一般的になっています。 最近どの程度価格が下がっているのかを考えると、このソリューションはあまりヒットせず、多くの場合、サイトの作業を大幅にスピードアップできます。 私の意見では、SSDの利点は次の2つのグラフです。
E3-1230、50の同時リクエスト
VPS、50同時リクエスト
ご覧のとおり、SATAディスクを搭載したサーバーでは、キャッシュによるバッファリングがすぐに停止し始めます。 同時に、SSDドライブを備えたVPSでは、一般的な傾向が続きます。 VPSでは、key_buffer_sizeおよびquery_cache_sizeの値をさらに増加させようとしました。そのため、取るに足らないが安定したパフォーマンスの向上が得られました（MySQLカーブ2）。 ただし、この段階では、両方の構成で、プロセッサはすでに窒息しています。
LoadImpactテスト
abユーティリティを使用して実行されたテストでは、サイトページの実際の読み込みは示されていませんが、パフォーマンスの質的な変化が示されています。 ある種の生活データに近いものについて、 Loadimpactを使用していくつかのテストを実施しました 。
- テストサイトのメインページには最大100個のSBUがエッチングされ、5つの異なる場所（アメリカに2つ、ヨーロッパに2つ、オーストラリアに1つ）にほぼ均等に分散されました。 合計グラフでは、サーバーがこの負荷に少なくとも少し負担をかけているかどうかを確認できません。
しかし、純粋に接続性の良いヨーロッパのポイントでグラフを見ると、負荷の増加がより顕著になります。
同時に、合計データストリームは90 Mbps近くでした。 私は棚にチャネルをキャッチしたかったが、ローンは残っていなかった。
プロセッサの負荷は顕著になりますが、負荷平均はabテストと比較されません。
- 結論として、私は通常の小さな情報SDLを複製し、その8つの異なるポイントからLoadimpactを設定しました。 すべてのテストポイントは、サイトの異なるページに向けられました。 10分で、SBUの数も100に達しました。
リターンは非常に均一で、明らかな減速はありませんでした。
同時に、サーバーは実際にこのテストに気付きませんでした。
結論の代わりに
2つの必須パラメーターのみでサイトの速度への影響を調べたので、トピックに関する追加の有用なヒントを提供できるすべての人に感謝します。 さらに、公開後約5日間、テスト環境は引き続き有効であり、最適化に関する他の推奨事項やテストの提案がある場合は、この期間中にそれらを実装して記事に追加しようとします。 最適化の経験とコツを共有してください。 そして、辛抱強く読んでくれてありがとう。