»WEB制作コード・プラグインWEBサービス・便利なサイトWordPressPhotoshopPC全般サイト運営お知らせ9ineBBWEB×DESIGN×CREATIVETwitterFacebookFeedlyFeed/RSSHOMEWEB制作系CMSWordPressWordpressの負荷軽減を本気でやってみたら負荷が1/3になったWordPressの負荷軽減を本気でやってみたら負荷が1/3になったTweet256PR最近サーバーのコンパネを見てなかったのですが、いつしか負荷が増えて503が頻発する自体になっていました。借りているレンタルサーバーはさくらインターネットのレンタルサーバーで、もう何年も利用しているものです。何個もWordpressのサイトを動かしていて結構こき使ってきてましたので、ここで改めてWordpressの負荷軽減を本気でやってみました。WordPressの負荷軽減策まず、なぜこんなに負荷が増えたのかってところから考えて攻撃が増えてきたアクセスが増えてきたプラグインが悪さしている(重たい)この両面から対策していくことにしました、まずは攻撃による負荷増大ですWordPressは世界一利用されているCMSです、そのぶん構造が周知されており攻撃の対象とされやすいです、攻撃自体はこれまで防げてきていますが攻撃自体がなくなっているわけではないまたこの攻撃ってのがGoogleアナリティクスとかのアクセス解析とかには出ないもので、サーバーでは単なるPVとしてしか認識されてないので判断しにくいのですが、攻撃されるポイントを塞いでしまおうということでそれからサーバーの負荷の減り具合をみて、実感すれば良いということで対策を練りますまた503が発生する理由としては短時間に集中してアクセス(プログラム実行)がおきてしまっているときです。ブログエディタやモバイルからのブログ投稿、ピンバック・トラックバックの処理などに使われています。自分のサイトでは、ピンバックもトラックバックも受け付けていません、さらにモバイルからの投稿もしてませんしブログエディタも昔は使っている時期がありましたが、現在はWordpressのビジュアルエディタの方が優秀になったので使う機会がなくなりました。いうことで、xmlrpc.phpの昨日は一切使っていませんので最も攻撃を受けやすいxmlrpc.phpへのアクセス制限を行うことにしました。アクセスを転送するWordPressのプラグインで対策するおもにこれらが対策の方法となると思いますが、Wordpressのプラグインを使う方法はまず無しです。プラグイン自体がサーバーへの負荷増大につながるので今回の目的は負荷軽減がメインですので。自体を削除する方法も基本的にはなしです、Wordpressのインストールフォルダの1階層目にあるファイルなのでFTPからサクッと消すだけで出来る最も簡単で.htaccessとかわからない人でも有効な対策ではありますが、Wordpressをアップデートする度に復活してしまいます。Wordpressのアップデートは上書き方式なので、消したファイルは新たに出来ます。そのため、Wordpressの更新をしてxmlrpc.phpの消し忘れがある溜め面倒です、またWordpressのサイトが多いとそのぶん対処が増えてきます。これが負荷に)以降同じとなります、xmlrpc.phpへのアクセスへのレスポンス自体はサーバーが返しているので負荷が発生しますxmlrpc.php自体を消してしまっても、ファイルがないというレスポンスをサーバーが返しているので同じく負荷があります。これは負荷に)2回目のサーバーへのアクセス実際には自分のサーバーにはアクセスしておらずアクセス元が転送先をキャッシュしており、ダイレクトに転送先へアクセスする(負荷なし)以降キャッシュされている限りこちらのサーバーには負荷は発生しないこういった原理です、1回目はどうじてもレスポンスが出ますが2回目以降はアクセス元が転送(リダイレクト)をキャッシュしている場合は直接キャッシュ先へアクセスします。アクセス元がキャッシュしない仕様ならばレスポンスが発生してシマノで負荷が発生してしまいますが、2回目以降のアクセスでの負荷ゼロが期待できます。いうのはサーバーのアクセス元の内部にアクセスだったと思います。アクセスが失敗しているのを簡単に見つけれます。今回はこの設定はこれまで通りで過ごそうと思います、IP指定でそれ以外はリダイレクト処理にするとことで負荷軽減も可能でしょうが、自身のPCのIPが変わった時にリダイレクトされてしまうとブラウザがキャッシュしてしまってキャッシュの削除とか面倒なので、そのままで行きます。アクセスを制限しています、固定IPの回線ではなくルーターの再起動等で自身のIPが変わってしまった場合はこのファイルを適時書き換えています。#許可するIPアドレス</Files>xxx.xxx.xxx.xxxのところには自身のIPを入れるところになります。続いては攻撃ではない普通のアクセスによるWordpressへの負荷軽減策となりますいろいろ調べるとWordpressにはwp-cron.phpっていう便利ではありながら厄介なものがあります、これは擬似的にcronを実現するためのファイルなのですが、これが一番負荷が高でした何をしているかと言うと、cronってのは定時にプログラムを実行させるためのものなのですがWordpress自身はそういうことが出来ません、なのでWordpressへのアクセスがあったときにWordpressが溜め込んだタスクをそのアクセスの時間を元に時間が過ぎているのかどうか判断してプログラムを実行させます。この時間の判断が実はアクセス毎なので相当負荷がかかっていると言えます、実際にタスクがなくても色々プログラムが走るので無駄な処理が多くなります。その他に対策を行うべきなのがプラグインの見直しキャッシュプラグインの設定の見直し単純に要らないプラグインを消しましょうということです、またキャッシュプラグインもサイトのスタイルに適したものにしましょうということです。実行されないためです、そのため予約投稿が実行されなかったのです。自身がサイトを見ると予約投稿が公開されたなんてこともあるでしょう、例えばローカルサーバーで立てたWordpressなんてのはアクセスが出来るのは自分自身なので予約投稿は機能しなかったりしますね。自体は使い方によって必要な機能だったりしますので、その点をケアしてやる必要がありますが、私のケースでは予約投稿を基本的に使ってなかったりするので今回は単純にwp-cron.phpの機能を停止してやって、必要になってくればサーバーのcronにて定時にwp-cron.phpの実行をさせて対処しようかと思います。'true');wp-config.phpというファイルがWordpressのインストールディレクトリにあるかと思います、それの最後らへんにでも書き加えてく保存してください、これでWordpressへアクセスがあってもwp-cron.phpは実行されなくなります。wp-cron.php自体の機能は死んでいないので、cronでこのファイルにアクセスしてやると動きはします。1時間100PVあるサイトなら、これを1時間に1回サーバーのcronで実行する形にするだけでwp-cron自体は機能させて1/100の負荷へと軽減出来たことになります。1時間に1回なので予約投稿とかはそのアクセスがあった時間に実行されることになりますので、この間隔を狭めてやりたい場合は実行時間の間隔を短くすればよかと思います。wp-cron.phpが大量に実行させないというところさえクリアできていれば良いので、cronによるwp-cron.phpの実行の間隔は意外と短くても問題は無いのだろうと思います。wp-cron.phpの標準の仕様がネックになるのは、アクセスが集中すればするほど実行されてしまう点ですから。WordPressのプラグインの見直しこちらは基本的に使わないプラグインを消しました、要るか要らないかはそれぞれのWordpressの使い方に大きく依存するので、熟考してプラグインを選別するしか無いです。WordPressのキャッシュプラグインの設定の見直しキャッシュプラグイン自体も負荷の原因にもなりえますが、設定を煮詰めることで最大のパワーを発揮させれます。キャッシュプラグインっていうのは有効にするだけでも十分に機能してますが、初期設定は無難な設定となっていますどのサイトでも問題なく動くだろうという想定の設定です。このプラグインを有効にしてそのままつかっていたのですが、細かくチェックしてみるとキャッシュの設定時間がとても短かったです、この設定だと結局のところはアクセスする度に処理が実行されるのでキャッシュ時間を変更しましたもともとは180秒のライフタイムのキャッシュで1時間で古いキャッシュの削除という設定でした、これはあまりにも短すぎる気がします、これをとりあえずは1時間ベースに置き換えましたライフタイムは3,600秒(1時間)、古いキャッシュの削除は86,400秒(24時間)もともとの2分設定はかなり更新が頻繁なサイトで一般的ではないでしょう、一時的なアクセス集中時には対応できるのかもしれませんが慢性的なアクセス集中には対応できないでしょう、ましてやページ数が多いサイトでは意味をなさないどころかキャッシュの生成にリソースを持ってかれて負荷が倍増するでしょう。キャッシュされた部分ってのは新たにページが投稿されたりすると、更新があった箇所は破棄されて新たにキャッシュが作られる用になったりするので新規ページってのはこのキャッシュ時間の長短の影響は無いでしょう。影響があるとしたら、既に投稿してある記事の変更やデザインの変更を行ったりしたケースだと思います、そういう場合はキャッシュ全てを破棄するボタンもありますのでその時にキャッシュをクリアしてやれば良いでしょう。ライフタイムは1時間、キャッシュの破棄は24時間にしましたがこれはまだ様子見です。毎時更新するようなサイトでも無いですし、コメントも大量に来るわけでもありませんのでもっと長くしても良いかと思います。キャッシュをうまく使えばスタティックなサイトと同等でありながらCMSの良さを取り入れることが可能ですので、キャッシュ設定は重要ですね。(有効だけしてちゃんと設定を煮詰めてなかったのを反省)WordPress負荷対策の結果どうなったかここまで色々とWordpressの負荷対策を施してきたわけですが結果的にどうなったか?ってのが重要ですね結果から言うと、直近のピーク時に比べてCPUの使用時間は1/3以下まで抑えることが出来ました、一部使い勝手は下がった面がありますが大した問題でも無いです。503発生はゼロになりました。青色がCPUの使用時間です、ピーク時は8時間超えでした。負荷対策は実は段階的に行って効果を見ながらだったので急激にガクンと落ちるのではなくジリジリ下がっていく形になっています。これはちゃんと効果がそれぞれあったのかを見るためです。あと、日単位なので丸一日効果を見るには数日空けてから次の対策って感じでやって行きました。サーバーへのPV自体も相当減りました、転送量も減りました、これはwp-cron.phpへのアクセス減、xmlrpc.phpへのアクセス減が相当効いている証拠だと思います、Googleアナリティクスではアクセスは普段と然程変化がない感じでもありましたのでユーザーが減ったってわけでも無いです。一方のグラフが503の発生回数です、9月27~9月30日のところ一旦ゼロとなっているのは、さくらインターネットのレンタルサーバーにあるブースト機能を試してみたからです、このブースト機能ってのはサーバーの処理能力を2日間大幅に解放してくれるもので、サーバーの処理能力が上がったことで503が発生しなくなったってことです。これをきっかけにサーバーの移転も考えましたが、負荷軽減をまずやってみるってことで結果的に成功しました。このサーバーでやって行けそうですね。小話ですが実は、この503大量発生が発覚したタイミングってのがさくらインターネットサーバー更新確定後だったわけですよ、サーバー乗り換えようにも1年更新が確定してしまっていてあとは支払い請求待だったわけで、請求される前に解約して他のサーバーへってのも出来なくはないんですがサーバー移転には時間の余裕を持ってやりたく月更新に変更したかったのですが期限が過ぎてたってわけで、もう負荷軽減やってみるしか無いってところだったわけです。サーバーにお金を潤沢に掛けれる人は、難しいこと考えなくてもサーバーを増強すれば解決できます。規模が大きくなればなるほど負荷軽減策による費用対効果は大きくもなりますけどね。あとはさくらインターネットのレンタルサーバーでメンテナンス期間でもあったのでその影響もある程度煽りを受けたのかなとも考えていますが大幅に負荷軽減ができ、また良い経験となりました。サイトのレスポンスもアップしたようで、ユーザーにもより快適にサイトが見てもらえるようになったんではないかと思います。4.7.3がリリース、脆弱性の修正が有りで更新推奨。キャンセル次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。