低速サーバ & WordPressでStatPress Reloadedのアクセスカウンタ機能を使う際の注意。

WordPressでアクセス解析をする方法も色々ありますが、つい最近までこのブログも組込みプラグイン型のアクセス解析として、StatPress Reloadedを使用していました。

StatPress Reloadedの良い所として、もちろんアクセス解析の結果が見やすいと言う点もありますが、自分が重宝していたのはアクセスカウンタ機能です。

StatPress Reloadedにはウィジェットとして当日、前日、累計のユニークユーザー数、ページビュー数などが手軽に表示できるアクセスカウンタ機能が搭載されているため、わざわざ別途アクセスカウンタプラグインを導入しなくても良いのでとても便利です。

 

しかしこの機能、やっていることは単純にアクセスログからそれぞれカウントしているだけのようで、月間ページビュー数が5,000前後のこの弱小ブログでもログ件数が増えてくるとだんだんとページ表示が遅くなっていきます。

それでも、多少遅いくらいならまあいいだろうと思って使っていたのですが、ある日大問題が起きました。

 

このブログ、勉強的な面も大きいためGoogle Analytics、ウェブマスターツール等外部のサービスも使用して様々な面からサイト状況を見ているのですが、ある日から突然ウェブマスターツールのサイト存在チェックでブログを認識しなくなってしまったのです。

何が理由かもわからないので焦りました。

しばらく（何日か）悩んでいましたが、ただ、ウェブマスターツールのエラー内容がサーバタイムアウトであることと、実際ブログの読み込みが若干遅いこともあり、ひょっとして・・・とStatPress Reloadedのアクセスカウンタを外してみると何事もなかったかのように認識し始めたのです。

 

結論としては、低速サーバ（安物の共用サーバやVPS）でStatPress Reloadedのアクセスカウンタ機能を使う際は、ログ量が増えてくると検索にコストがかかり、他のサービスに影響を及ぼすと言うことがわかりました。

 

もちろん、StatPress Reloadedも常に無尽蔵にログを貯め続けるのではなく、オプションでログ保存期間を変更できます。

普段、ただのアクセス解析ツールとして使用する分には、半年、長くても1年くらいで削除するように設定しておけばパフォーマンス面から見てもいいでしょう。

ただ、アクセスカウンタとして使う場合はそうはいきません。例えばログ保存期間を半年にしてしまうと、トータルページビューが半年分のカウント数になってしまいます。また、Sinceが半年前になってしまいます。なぜなら、StatPress Reloadedは一つのテーブルでしかログを管理していない為、「ログが消える=カウント対象から消える」と言う状態になってしまうからです。

かと言って、ログ保存期間を無期限(Never delete!)にしてしまうと、サイトパフォーマンスが落ち今回のような想定外のトラブルが発生してしまいます。

 

同じ状況に遭遇する人もなかなかいないかと思いますが、失敗例として記録しておきます。