包括的なWordPressウェブサイト最適化

ハブルの親愛なる居住者！



サイトをどのように最適化したかについてのストーリーが表示されます。 このサイトはWordpressエンジンで実行されます（このフレーズでは、ほとんどの読者はWordPressが高速でどのように機能しているかを知ってしかめっ面をする必要があります）。 しかし、私たちは成功し、サイトは飛び始めました。 私はサーバー最適化の専門家とはみなされないことをすぐに言わなければなりませんが、私が達成したことは私にとって非常に楽しいです。 また、貴重な経験が得られ、Habrの読者と共有したいと思います。

行こう

まず、サイトの阻害の原因を調査することから始めました。 個人的には、 LoadImpactサービスが最も気に入っています。 少し前まで、彼は新しい機能と新しいインターフェースを持ち、サービス自体は「LoadImpact 2.0」と呼ばれ始めました。 これはすべて広告用ではないと言われています-サービスは本当に良いです。 Pingdom Full Page TestとGoogle PageSpeedのようなサービスを使用してサイトをテストすることもできます。



Load Impact Page Analyzerを使用して、Time to first byteパラメーター（4秒）の大きな値を見つけました。これは、ページを形成するPHPスクリプトが長時間実行されていることを示しています。 サイトの最も阻害的なコンポーネントを検索する必要がありました。



footer.phpテンプレートに行を追加する



<!-- <?php echo get_num_queries(); ?> queries -->







メインページを生成するのに82のSQLクエリが必要であることがわかりました。 WordPressモジュールの数と、それらを使用するSQLクエリの数を減らす必要があることが明らかになりました。 インストールされたWordPressプラグイン（約40個）を整理すると、結局のところ、それらのほとんどが本当に必要であることがわかりました。



テンプレート内のすべてのPHPコードをプロファイルすることにしました。 Xdebug + Performance Testingは気にしませんでした（このため、サードパーティのソフトウェアを大量に配置する必要がありました）が、次の形式の簡単な自己記述型プロファイリングを行いました。



<!-- HEADER01 - <?php print microtime(true) ?> -->







次の主な問題をすぐに発見しました。

• ジオターゲティング広告モジュール
• Apple株価表示モジュール
• サイドブロック「アプリケーションの概要」と「ハイライト」

これらの問題のそれぞれは、綿密な調査の際に、基準面を引き起こします。 次に、それぞれについて説明します。

回

私たちのサイトの最大のブレーキは、ジオターゲティング広告モジュールです。 その本質は、サイトに2種類のバナーが表示されることです。1つはサンクトペテルブルクからの訪問者用に、もう1つは他のすべてのバナー用に表示されます。 モジュールを詳しく調べてみると、govnokodが見つかりました。

 if（$ ip_part）
 {
 for（$ y1 = $ ip_part [0] ['start']; $ y1 <= $ ip_part [0] ['end']; $ y1 ++）
 for（$ y2 = $ ip_part [1] ['start']; $ y2 <= $ ip_part [1] ['end']; $ y2 ++）
 for（$ y3 = $ ip_part [2] ['start']; $ y3 <= $ ip_part [2] ['end']; $ y3 ++）
 for（$ y4 = $ ip_part [3] ['start']; $ y4 <= $ ip_part [3] ['end']; $ y4 ++）
 {
 $ ip [] = $ y1。 "。"。$ y2。 "。"。$ y3。 "。"。$ y4;
 if（$ ip_addr == $ y1。 "。"。$ y2。 "。"。$ y3。 "。"。$ y4）trueを返します。
 }
 }

この瞬間、私はプロセッサーに少し申し訳なく思っていました。



サンクトペテルブルクのIPアドレスの初期範囲は、事前に$ ip_part配列に設定されています。 このコードからわかるように、関数を呼び出すたびに、何らかの理由で、$ ipの動的配列が作成され、4つのネストされたループを通じて愚かな方法でIPアドレスを持つ文字列（！）データで埋められました。 ループの各反復で、訪問者のIPアドレスが行（！）と結果のIPアドレス文字列と比較されました。 これを修正するのは簡単でした：

 $ ip_tmp = explode（ "。"、$ ip_addr）;
 if（$ ip_part）
 if（（$ ip_part [0] ['start'] <= $ ip_tmp [0]）and（$ ip_tmp [0] <= $ ip_part [0] ['end']））
 if（（$ ip_part [1] ['start'] <= $ ip_tmp [1]）および（$ ip_tmp [1] <= $ ip_part [1] ['end']））
 if（（$ ip_part [2] ['start'] <= $ ip_tmp [2]）および（$ ip_tmp [2] <= $ ip_part [2] ['end']））
 if（（$ ip_part [3] ['start'] <= $ ip_tmp [3]）および（$ ip_tmp [3] <= $ ip_part [3] ['end']））
 trueを返します。

このコードをより最適に書き換えることができることは否定しませんが、この編集を行った後でも、サイトは2秒速くなりました！

二

2番目のプラグインはEmbedded Stock Dataと呼ばれ、このページにはAppleの引用が表示されています。 この爬虫類は、ページがロードされるたびにCURLを介して別のサイト（！）に移動することが発見されました。 当然、これによりページのロード時間が大幅に増加しました。 彼らは問題を自然な方法で解決しました-サーバー上でクラウン上でスクリプトが1分に1回呼び出され、必要な見積もりをダウンロードして特別なファイルに保存しました。 次に、このファイルを含めました。 これにより、約500ミリ秒かかりました。

三

サイドブロックの「アプリケーションの概要」と「最も興味深い」も具体的な時間を実行しました。 テンプレート（sidebar.php）の内部を見ると、「ORDER BY RAND（）」と呼ばれる初心者のWebプログラマーの古典的なエラーを見ました。 この問題の本質については、たとえばこちらをご覧ください 。



興味がある人のために、そのようなコードがありました：

 $ args = array（
 'caller_get_posts' => '1'、
 'post__not_in' => $スティッキー、
 'cat' => '75'、
 'fields' => 'ids'、
 'post_per_page' => '20'、
 'orderby' => 'ID'、
 ）;
 $ sk_count =新しいWP_Query（$ args）;

 $ args = array（
 'caller_get_posts' => '1'、
 'post__not_in' => $スティッキー、
 'showposts' => '4'、
 'cat' => '75'、
 <b> 'orderby' => 'rand' </ b>
 ）;
 $ sk_posts =新しいWP_Query（$ args）;

その中で、選択した行を

 'post__in' => array_rand（array_flip（$ sk_count-> posts）、4）

ソリューションの本質-最新の20個のエントリを事前に選択してから、これら20個のエントリからランダムに4個を選択し、データベースからこれらの番号の投稿を選択します。



これにより、さらに0.5秒節約できました。

Clodoへの移行

私たちの鉄のサーバーは当初、多数のサイトをホストしていましたが、トラフィックと価値の面で最も重要なのはAppleInsider.ruでした 。 このサイトを他のサイトの近くから保護したかったため、 Clodoクラウドに転送することにしました 。 Clodoの主な利点は、料金の「弾力性」と呼ぶことができます-どれだけのリソースを使うか、あなたはそんなに払うのです。 心を込めて、VIP以外のバージョンでも正しく動作し、すべてのトリッキーな質問に答え、実際のセットアップに役立った会社のテクニカルサポートに注目したいと思います。



転送で「静かに」、いくつかの変更が行われました。たとえば、完全に重いApache Webサーバーを削除し、代わりにnginx + php-fpmを大量に作成しました。 Nginxは通常のスキームに従って動作しました-静的を返し、他のすべてはindex.phpスクリプトにリダイレクトされ、そこにはさらにWordPressロジックがあります。



nginx + php-fpm Webサーバーに割り当てられたアイロンのリソースを消費しないように、MySQLデータベースサーバーを別のサーバーに移動し、ローカルネットワーク経由でWebサーバーに接続しました。



また、 AppleInsider.ruポッドキャストとAppleコア、およびオンラインテキストブロードキャスト用に、 2つの個別の「クラウド」サーバーをセットアップしました。 次回はそれらについて詳しく説明します。



Clodoに切り替えてもページ生成時間は大幅に短縮されませんでしたが、サイトは安全になりました。

WPスーパーキャッシュと非同期広告

この段階では、約1秒でページが形成されました。 すでに悪くはありませんが、最適化できる点がまだいくつかあったため、私たちにとっては十分ではありませんでした。



たとえば、 WP Super Cacheと呼ばれるプラグインを使用してWordPressページをキャッシュします。 通常のキャッシュのように機能します-ユーザーがページにアクセスすると、生成され、/ wp-content / cache / supercacheディレクトリに配置されます。 次の訪問者には、既に静的な事前生成されたHTMLファイルが提供されます。 すべてがスーパーだと思われる-サイトが飛んでいる...



しかし、キャッシングの使用がジオターゲティング広告を壊したことがすぐに発見されました。 サンクトペテルブルクの住所範囲での訪問者の住所の確認は、PHPレベルで実行されました。 すでにキャッシュ用です。 したがって、このチェックの結果は「永久に」キャッシュに残りました。 ただし、バナーの表示を区別する必要がありました。



この問題を次のように解決しました-ページテンプレートで、Javascipt命令が適切な場所に配置され、特定のURLからこのdivブロックにコンテンツをロードする必要があることを示しました。 したがって、ユーザーはJavascript命令を含むキャッシュされたページを自由に受け取り、最初の文字が表示された後、サイトの広告およびその他の構造ブロックは個別の特別なURLに保存されます。 視覚的には、これは非常に迅速に発生します。 そのため、2つの目標を達成することができました。1つ目は、キャッシュによりサイトが大幅に高速化され、2つ目は、ジオターゲティング広告が正しく機能することでした。

Clodostorage

最適化で最後に行ったステップは、静的コンテンツ（画像、CSSスタイル、Javascript）をCloudStorageに転送することでした。 詳細はこちらをご覧ください 。 一言で言えば-これはClodoのコンテンツ配信ネットワークであり、ロシア語では-非常に高速なサーバーであり、統計の配信用に特別に強化されています。



WordPressとの統合は、CDN同期ツール（Clodoの場合はPHP Cloud Files APIライブラリの特別なビルドを使用する必要があります ）とWPスーパーキャッシュの2つのプラグインの適切な構成で構成されます。



最初のプラグインであるCDN Sync Toolは 、WordPressコンテンツをリポジトリにアップロードし、同時にこのコンテンツでいくつかのアクションを実行することを約束します。 WP Minifyプラグインを使用すると、 CSSおよびJSファイルを圧縮できます。 また、ダウンロードした画像をその場で圧縮することもできます。 この場合、GDライブラリが使用されます。私たちにとって最も受け入れられる圧縮レベルはGD圧縮レベル= 2でした。他のプログラムに関しては、これは90％の品質です。 もちろん、最も重要なことは、著者による画像の標準的な読み込み中に、それらが自動的にリポジトリにアップロードされ始めたことです。



静的については、別のサブドメインstatic.appleinsider.ruを作成し、Cyber​​Duckを使用してコンテンツの初期読み込みを行いました。Cyber​​Duckは、FTP、SFTP、WebDAV、クラウドファイル、Google Docs、Amazon S3を操作するためのかなり便利なプログラムです。



Clodo用に調整されたCDN Sync Toolプラグインのスクリーンショットを次に示します（クリック可能）。







2つ目のプラグインは既に説明しましたが、WPスーパーキャッシュです。生成されたページを取得し、静的ファイルのすべてのURLをリポジトリ内のURLに置き換えます。 たとえば、 http：//www.appleinsider.ru/Angry-Birds.jpgはhttp://static.appleinsider.ru/Angry-Birds.jpgになります

まとめ

キャッシュにページがない場合、ページは1.25秒でロードされ、キャッシュにある場合は250ミリ秒かかります。これは、4つの要因すべてを考慮して、DNSルックアップ+接続+最初の時間+ダウンロードです。 これは驚くべき結果だと思います！



結論として、私は乾燥した事実を引用します-リソースの使用と統計的コストの統計。



2011年11月23日から2011年11月30日までの1週間の作業：

Web

スケールサーバー-RAMリソース	45708.00 GB *分	457,080ルーブル
スケールサーバー-CPUリソース	1027116.50 CPU秒	427.300こする。
ディスク使用率	5760.00 GB *時間	57.600こする。
着信トラフィック（フルギガバイト）	34 GB	6.800こする。
発信トラフィック（フルギガバイト）	129 GB	129.870 RUB
バックアップにディスクを使用する	1910.00 GB *時間	19.100 RUB
SMS通知	1個	5.000こする。
アカウントから引き落とされた合計		1102.75 RUB

DB

スケールサーバー-RAMリソース	22924.00 GB *分	229.240 RUB
スケールサーバー-CPUリソース	67490.34 CPU秒	RUB 28,080
ディスク使用率	3840.00 GB *時間	38.400こする。
着信トラフィック（フルギガバイト）	1 GB	0.200こする。
発信トラフィック（フルギガバイト）	12 GB	12.000こする。
バックアップにディスクを使用する	1910.00 GB *時間	19.100 RUB
アカウントから引き落とされた合計		327.02ルーブル

クラウドストレージ

クラウドストレージ-ディスク使用量	1139.00 GB *時間	11.390 RUB
クラウドストレージ-インバウンドトラフィック（フルギガバイト）	-	充電されていません
クラウドストレージ-アウトバウンドトラフィック（フルギガバイト）	330 GB	330.000こする。
アカウントから引き落とされた合計		341.39 RUB

サイトの作業のわずか1週間-1771.16ルーブル。 かなりたくさんありますが、安定性と満足したユーザーは価値があります:-)



あなたのコメントを本当に楽しみにしています。