毎年恒例になってまいりました。
iconDecotterが基本的に一年で最もビジーになるのが12/26です。
2015年：昨年末を振り返ってサーバー負荷を見直す
2014年：MySQLをチューニング
今年は、直前にbeforeアイコン（デコレーション前の画像）を保存しているオブジェクトストレージに障害が起きて、一番忙しい時期に一切繋がらなくなるというトラブルが発生して、急遽ストレージをGoogle Cloud Storageに切替えるという事件が起きていましたが、負荷対策的にはあまり問題になってなさそうでその点はよかったです。
GoogleAnalytics（20161221-20161227：時間別）
さくらVPSリソースグラフ（20151221-20151227）
●一年前からの主なサーバーサイド変更点
・PHP5→7
・Web-DBの2台構成化
・Apache設定のチューニング
・一部の静的コンテンツをGoogle Cloud Storageに設置
・さくらオブジェクトストレージ→Google Cloud Storageに切替
総評
アクセス数は昨年よりも増えているのですが、DISC/IOが全然少なくなっていますね。
何でかってこれは昨年までのApache設定がダメすぎて、スワップ起きまくりだったわけなんですね。
現在は、ちゃんとApacheプロセスのメモリ量とサーバーのメモリ総量を比べて、適切なMaxCliantの数を設定しているので、ほぼスワップ発生してなかったかと思います。
また、それでも今年のピーク時にはあまりサイトが重くなるようなことも無かったようなので、上手く乗り切れた感じです。
実はWebサーバーを分けた後からちょっと前まで、Apache設定でKeepAliveをON（KeepAliveTimeoutは2）にしていたんですが、そうするとこのピークの半分くらいのアクセス量でもサイトが繋がらなくなるとかいうことが起きてました。
MPMはPreforkだったのですが、こういうサイトでそれをやるとかなりマズかったようで、CPUやメモリにはとても余裕があるのに何故かサイトに繋がらないみたいなことになってました。
KeepAliveをOFFにしたところだいぶ改善されたので、MPMを変更しない限りはこのままで行こうと思います。
一部のJSや画像要素をGoogle Cloud Storageに置いて、そこから呼ぶようにしたのもだいぶ負荷対策になったかと思います。今はフレームのサムネイル画像もそっちに置いてますが、転送量が結構あるので、ちょっと考えないと費用がかかりますね…。
ただ、503になることなどまず無かったようなので、やはり強力ですね。
コメント