Coreserverなのでなるべくサーバー負荷を減らすべく、WordPressのプラグインを中心に弄ってみました。その結果、coreserverへ掛かる負担は減少し、Webページの表示スピード評価も良くなりましたので簡単に報告します。
本ブログはValue-Domainにてドメインを取得し、Coreserverにて運営しています。それらを選択している理由はランニングコストが非常に安く、結構自由な設定も可能だからです。ランニングコストの内訳は、年間のJPドメイン管理料約3000円+サーバー代金約5000円ですので、年間1万円も掛けていません。ドメインやサーバーの選択次第ではもっと安くも出来ますね。1つのサーバーに何人かのユーザーが共存する共用サーバーで運用することで月額コストを低く出来ているようです。胸痛サーバーゆえ、リソース(CPUやメモリ)も共有して使用することとなりますので、負荷が掛かるプログラムを動かす際には他人に迷惑をかけないよう気を付けながら運用しなくてはいけません。(あまりにも高負荷を継続すると制限が掛かっちゃいます)
ブログなどのコンテンツを作成するCMS(Contents Management System)には、アクセス毎にデータベースからページを生成する『動的』なものと、投稿をしたときにHTMLを書き出す『静的』なものがあり、WordPressは動的なCMSで、静的なCMSにはmovableType等がありますね。どちらがサーバー負荷をかけるかは一概には言えないのですが、投稿数もアクセス数も同じであれば動的なCMSの方がサーバーに負荷をかけるのではないでしょうか。
ということで、サーバー負荷低減の方針でプラグインを設定してみました。
目次
余計なプラグインの削除
まず始めに、使っていないプラグインの停止→削除を行いました。興味本位で入れたままになっていルプラグインは使っていなければ削除しちゃいましょう。もちろんバックアップを忘れずに。
動的なページ生成をやめ、キャッシュを利用して静的に
SuperCacheでプリロード(あらかじめキャッシュを作っておく)の設定を行いました。デフォルトではアクセス毎にキャッシュを作っていくプラグインなので、初回のアクセスに対しての表示スピードがサーバーによる記事生成処理を挟む分、高速化の恩恵を受けられません。2回目以降のアクセスに対してはキャッシュでの対応になります。
プリロードを行うことで全てのページがキャッシュされるため、初回のアクセス時に素早いページの表示が可能になります。しかし、プリロード中はサーバーへの負荷が掛かるため、実施時刻をアクセスの集中がしにくい時間帯に設定するなどの工夫が必要だと思います。
複数のプラグインをWordpress純正の一つのプラグインへ移行
JetPackを導入しました。すべての機能を有効にしたわけではなく、エディタ拡張やソーシャルネットワーク、サイト監視関連、スパム削除などの機能を有効にしました。
数年間も更新されていないプラグインのうち、JetPackの機能で代替できる物は削除しました。更新されていないプラグインはセキュリティ的にも脆弱だと思われます。
上記の設定を行ったところ、アカウント毎の負荷率が50~600の間(平均200弱)で推移するようになりました。もっと負荷率を減らしたいところですが、難しそうです。