いつの間にかWordPressのCPU使用率がどえらいことに! 9つの改善案

前々から薄々気づいてはいたのですが、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」もすごく低い値…
必要以上にこだわらず、やりすぎにならない程度でなんとかこのあたり改善しようと考えてみました。

※大抵そうなんですが、共有サーバで提供のものやMRTG、Zabbixなどの「CPU使用率のグラフ」では数分間の平均CPU使用率のグラフだったりする訳で、それだと使用率の平均は間引きされて見えCPU負荷が低く見えてしまいがちです。

WordPressの最適化について考えて見ました

WordPressロゴ瞬間的なCPU使用率が高いってことは、同時に捌けるキャパが低く、また、表示も遅く、mod_deflateなどでコンテンツをgzipで圧縮してネットワークのボトルネックを抑えたとしても表示レスポンスが遅いので効果が薄い、または、逆効果なんてことになっちゃいます。また、SEO的にもクロールの影響や、ページビュー・直帰率あたりにも影響がでると思いますし、いいことないと思います。

まずは、MySQLについてですが、本体ならまだしもプラグインも含めて最適なSQL文がはかれているとは思えないので、「MySQLTuner-perl」などでほどほどにチューニングはしておけば良いと思われます。こだわりすぎて、MySQLに必要以上のバッファサイズ等のリソースをあてても、そんなに改善されるとは思えません。

じゃあ、やっぱりPHPやWordPressの最適化がメインになると思うのですが、今回はWordPressに着目して考えていこうと思います。本件についてググると関連する下記のような情報がいっぱい見つかりました。

上記の記事を筆者の主観でまとめますと下記のとおりです。
※列挙すると、当たり前の内容になってしまいました。「当たり前じゃん」的なツッコミはなしでお願い致します。

WordPressの最適化 ー 9つの改善案

  1. WordPress本体を最新版にする

    最新版がすべて良いという訳ではありませんが、恐らく最新版だと、よりリファクトされた処理効率の良いコードである可能性が高いと思います。

  2. WordPressのプラグインを最新版にする

    上記と同様な理由ですが、プラグインは小規模な体制で開発されたものもあり、最新版の方が処理効率的に良くないことが多いかもしれません。

  3. プラグインを可能な限り減らす

    全てのプラグインを削除してCPUを測定すると、たしかにCPU使用率も処理能力的にも2倍程度良くなりました。ネット視聴者がアクセスの際に重い処理が動くプラグインはもちろんのこと、そのプラグインが管理画面向けのものであっても少量ではありますがCPU使用率も処理能力的にもよくない結果になりました。おもしろいからといってむやみにプラグインを、例えば50、60個などインストール・有効化すると1つ1つは少量でも大変な負荷になるのではと思います。

    ※特に下記のプラグインは重いので本当に必要なものだけに留めるか代替プラグインに変える(筆者でも確認したのですが、下記のプラグインは他のものよりも重かったです)。

    • 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)
  4. 無効なプラグインは削除する

    プラグインは無効化されていても、アップデート通知などの処理負担となるので、可能であれば削除しておいた方がよさげです。

  5. 標準で動くWP-Cronを停止し、OSのcronでWP-Cronを実行する

    皆様も1分間毎の平均CPU使用率で見ると、たいして負荷がかかっていないのではないでしょうか。タイミング的にWP-CronはWordPressにアクセスの際に実行されるのですが、ネット訪問者がアクセスの際の突発的な高CPU負荷の瞬間に動く必要があるのでしょうか。それを止めて、OSのcronで実行してあげれば、CPUが空いているときにWP-Cronが動く確率が高くなると思います。

  6. 可能な限りウィジェットを減らす

    重いウィジェットを外せば表示する際の処理負荷を減らせられます。

  7. 可能な限りfunctions.phpのロジックを減らす

    functions.phpもプラグイン同様、表示する際の処理負荷につながります。

  8. キャッシュ・プラグインを活用する

    ケースバイケースではありますが、実は、上記1~7については、可能であればっという程度のもので、効果もそれなりかもしれません。しかし、このキャッシュ・プラグインは効果覿面です! キャッシュ・プラグインにもいろいろなものがありますが、有名なものとしては、「Quick Cache」「WP Super Cache」「W3 Total Cache」あたりじゃないでしょうか。

    筆者としては安定稼働を1番重要視していましたので、いままでキャッシュ・プラグインは敬遠していました。従って、あまり詳しくないのでググって調べてみました。

    Quick Cache
    WP Super Cache」の後継型?発展型?フォーク?らしいのでご選択されておられる方もいらっしゃいました。実際に動かして確かめてないのですが、PHPによるページキャッシュ?

    WP Super Cache
    コード古い? 実際に動かして確かめたのですが、ページキャッシュに「PHPモード」「mod_rewriteモード」の2つのモードがあって、「PHPモード」は性能結果がいまいちでしたが、「mod_rewriteモード」では、生成された静的なHTMLにmod_rewriteしてくれるので、キャッシュされるとPHPは動かずApache側だけでページ表示してくれて、劇的にCPU負荷も下がり「Requests per second」も上がりました。

    W3 Total Cache
    恐らくこれがこの3つの中で1番高性能! キャッシュの仕組みもページキャッシュ・オブジェクトキャッシュ・データベースキャッシュがあります。でも下記のような記事も見つけました。

    設定にもよると思うのですが、高機能ゆえにサーバリソースが潤沢でないと実は相当厳しいプラグインらしいです。

    では、1番無難なものはどれ?、速さの比較は?と調べると、下記のとおり調べてくれている方がいらっしゃいました。

    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」を検証したいと思いました。

  9. OSを複数のCPU・コア・スレッドで!

    上記8のものでページキャッシュしたとしても、最初のキャッシュ生成時に突発的なCPU負荷がかかってしまいます。複数のCPU・コア・スレッドであれば、このあたりが誤魔化せるんじゃないかと…
    結局は「力技かいw」ってツッコミはなしでお願いします。

これらでネット訪問者がアクセスの際の突発的なCPU負荷も軽減され、mod_deflateが安定的な処理スピードで捌ければ、よりページ表示も高速になると思います。以上、Webサイトによってケースバイケースのところがあり、検証がとても重要ですが、皆様のご参考になりましたら幸いです。