前々から薄々気づいてはいたのですが、WordPressが稼働しているWebサーバでTOP/vmstatコマンドをたたくと…たまぁ~に瞬間的な高CPU使用率に！ 今回は、このあたりの最適化について考えてみました。その前に、CPU使用率の測定コマンドについてご紹介します。
瞬間的なCPU使用率の測定
topコマンド
Redhat系OSのprocpsパッケージに含まれています。defaultでは5秒？間隔なので、-dオプションで間隔(秒)を指定します。1秒未満の間隔も指定できます。
# top -d 1
vmstatコマンド
Redhat系OSのprocpsパッケージに含まれています。引数に間隔(秒)を指定します。デフォルトではCPU負荷状況を表示しますがオプションでディスク統計状況等も表示できます。
# vmstat 1
sarコマンド
Redhat系OSのsysstatパッケージに含まれています。引数に間隔(秒)と繰り返す回数を指定します。デフォルトではCPU負荷状況を表示しますがオプションでディスク負荷状況等も表示できます。
# sar 1 100
pidstatコマンド
Redhat6系OSのsysstatパッケージに含まれています。残念ながら、Redhat5系のsysstatはバージョンが低く含まれてませんでした。引数に間隔(秒)を指定し、動きのあったプロセス毎のCPU負荷を表示できます。
# pidstat 1
また、abコマンド(Apache Bench)で1秒間に捌ける性能「Requests per second」もすごく低い値…
必要以上にこだわらず、やりすぎにならない程度でなんとかこのあたり改善しようと考えてみました。
WordPressの最適化について考えて見ました
瞬間的なCPU使用率が高いってことは、同時に捌けるキャパが低く、また、表示も遅く、mod_deflateなどでコンテンツをgzipで圧縮してネットワークのボトルネックを抑えたとしても表示レスポンスが遅いので効果が薄い、または、逆効果なんてことになっちゃいます。また、SEO的にもクロールの影響や、ページビュー・直帰率あたりにも影響がでると思いますし、いいことないと思います。
まずは、MySQLについてですが、本体ならまだしもプラグインも含めて最適なSQL文がはかれているとは思えないので、「MySQLTuner-perl」などでほどほどにチューニングはしておけば良いと思われます。こだわりすぎて、MySQLに必要以上のバッファサイズ等のリソースをあてても、そんなに改善されるとは思えません。
じゃあ、やっぱりPHPやWordPressの最適化がメインになると思うのですが、今回はWordPressに着目して考えていこうと思います。本件についてググると関連する下記のような情報がいっぱい見つかりました。
- How to Reduce CPU Usage and Minimize Server Load
- How To Fix High-CPU Usage In WordPress
- 10 Ways to Reduce Hosting CPU Usage on WordPress
- How to fix high-CPU load in WordPress
上記の記事を筆者の主観でまとめますと下記のとおりです。
※列挙すると、当たり前の内容になってしまいました。「当たり前じゃん」的なツッコミはなしでお願い致します。
WordPressの最適化 ー 9つの改善案
-
WordPress本体を最新版にする
最新版がすべて良いという訳ではありませんが、恐らく最新版だと、よりリファクトされた処理効率の良いコードである可能性が高いと思います。
-
WordPressのプラグインを最新版にする
上記と同様な理由ですが、プラグインは小規模な体制で開発されたものもあり、最新版の方が処理効率的に良くないことが多いかもしれません。
-
プラグインを可能な限り減らす
全てのプラグインを削除してCPUを測定すると、たしかにCPU使用率も処理能力的にも２倍程度良くなりました。ネット視聴者がアクセスの際に重い処理が動くプラグインはもちろんのこと、そのプラグインが管理画面向けのものであっても少量ではありますがCPU使用率も処理能力的にもよくない結果になりました。おもしろいからといってむやみにプラグインを、例えば５０、６０個などインストール・有効化すると１つ１つは少量でも大変な負荷になるのではと思います。
※特に下記のプラグインは重いので本当に必要なものだけに留めるか代替プラグインに変える(筆者でも確認したのですが、下記のプラグインは他のものよりも重かったです)。- NextGen Gallery
- Yet Another Related Posts Plugin
- All In One SEO
- Broken Link Checker.
- Captcha
- Akismet
- Google XML Sitemaps
- Google XML Sitemaps for Images
- WP-Optimize
- ShareThis ( Use Coding instead of Plugin. You can get coding on ShareThis Official Website)
-
無効なプラグインは削除する
プラグインは無効化されていても、アップデート通知などの処理負担となるので、可能であれば削除しておいた方がよさげです。
-
標準で動くWP-Cronを停止し、OSのcronでWP-Cronを実行する
皆様も１分間毎の平均CPU使用率で見ると、たいして負荷がかかっていないのではないでしょうか。タイミング的にWP-CronはWordPressにアクセスの際に実行されるのですが、ネット訪問者がアクセスの際の突発的な高CPU負荷の瞬間に動く必要があるのでしょうか。それを止めて、OSのcronで実行してあげれば、CPUが空いているときにWP-Cronが動く確率が高くなると思います。
-
可能な限りウィジェットを減らす
重いウィジェットを外せば表示する際の処理負荷を減らせられます。
-
可能な限りfunctions.phpのロジックを減らす
functions.phpもプラグイン同様、表示する際の処理負荷につながります。
-
キャッシュ・プラグインを活用する
ケースバイケースではありますが、実は、上記１~7については、可能であればっという程度のもので、効果もそれなりかもしれません。しかし、このキャッシュ・プラグインは効果覿面です！ キャッシュ・プラグインにもいろいろなものがありますが、有名なものとしては、「Quick Cache」「WP Super Cache」「W3 Total Cache」あたりじゃないでしょうか。
筆者としては安定稼働を１番重要視していましたので、いままでキャッシュ・プラグインは敬遠していました。従って、あまり詳しくないのでググって調べてみました。
Quick Cache
「WP Super Cache」の後継型？発展型？フォーク？らしいのでご選択されておられる方もいらっしゃいました。実際に動かして確かめてないのですが、PHPによるページキャッシュ？WP Super Cache
コード古い？ 実際に動かして確かめたのですが、ページキャッシュに「PHPモード」「mod_rewriteモード」の２つのモードがあって、「PHPモード」は性能結果がいまいちでしたが、「mod_rewriteモード」では、生成された静的なHTMLにmod_rewriteしてくれるので、キャッシュされるとPHPは動かずApache側だけでページ表示してくれて、劇的にCPU負荷も下がり「Requests per second」も上がりました。W3 Total Cache
恐らくこれがこの３つの中で１番高性能！ キャッシュの仕組みもページキャッシュ・オブジェクトキャッシュ・データベースキャッシュがあります。でも下記のような記事も見つけました。設定にもよると思うのですが、高機能ゆえにサーバリソースが潤沢でないと実は相当厳しいプラグインらしいです。
では、１番無難なものはどれ？、速さの比較は？と調べると、下記のとおり調べてくれている方がいらっしゃいました。
Test of WordPress Caching Plugins – W3 Total Cache vs WP Super Cache vs Quick Cache
http://www.dashboardjunkie.com/test-of-wp-caching-plugins-w3-total-cache-vs-wp-super-cache-vs-quick-cacheとりあえず、筆者は「WordPressの動きが複雑化しそうなオブジェクトキャッシュ・データベースキャッシュまではいらない」「そこまで高速化しなくても」「不具合か何かあったらソースコードを追えるくらいの規模のものを」と思い、無難そうな「WP Super Cache」を検証したいと思いました。
-
OSを複数のCPU・コア・スレッドで！
上記8のものでページキャッシュしたとしても、最初のキャッシュ生成時に突発的なCPU負荷がかかってしまいます。複数のCPU・コア・スレッドであれば、このあたりが誤魔化せるんじゃないかと…
結局は「力技かいｗ」ってツッコミはなしでお願いします。
これらでネット訪問者がアクセスの際の突発的なCPU負荷も軽減され、mod_deflateが安定的な処理スピードで捌ければ、よりページ表示も高速になると思います。以上、Webサイトによってケースバイケースのところがあり、検証がとても重要ですが、皆様のご参考になりましたら幸いです。