サーバの最適化を行って、サーバ台数を5台くらい減らした。

   

 

CopyContentDetectorをいろいろ見直しを行いました。

地味で地味でたいへんな作業でしたが、現時点でかなり最適化とサーバの圧縮に成功したと思います。大体5台くらいサーバ減らせました。

PHPのプロファイリングはblackfireを利用しました。とても良かったです。

 

■見直したこと

▼マスターデータベースのINDEXの見直しとSQLの見直し

ちょっとIOWaitが高かったんです。なので見直しました。

目標値は「long_query_time0.2秒に設定して、slow queryログに何もでないようにする」という基準にしました。現状達成することができています。

 

・データの偏りでINDEXの効き方が変わってきたのでINDEXの見直し

いままでINDEXで利用されていたのが、データの偏りでフルスキャンになったりしていたので、いろいろ見直しました。 基本に忠実に遅いクエリをexplainで一つずつ潰していきました。

 

・フレームワークを使ってselect * とかして全カラム取得していたのを見直し

Cakephp使っていて、find使っていたのですが、その処理で使っていないカラムのデータも取得していました。無駄を減らしました。

 

・繰り返し取得するデータに関してはmemcacheに一定保持することでデータベースにアクセスしないようにした

チェックバッチで何度も取得するようなデータに関してはmemcacheにデータを保持するようにすることで、データベースへのアクセスを減らしました。

 

★結果

良くなりました。IOWAITですが、かなり減りました。伴ってその他のCPU利用率もかなり効率化されました。

 

▼コードの見直し(これが一番効果があった)

今回はプロファイリングにblackfireを利用しました。PHP7でも動くプロファイリングツールです。コールグラフなんかも作ってくれて今回とても助かりました。

 

・CakePHPを使わなくて良い箇所は使わなくした

CopyContentDetectorでは、各種テキスト処理はAPIみたいな感じにして、バッチから処理を分離しています。

フレームワークは便利なのですが、プロファイリングをするとフレームワークの実行だけで結構な実行時間を消費します。何もしなくても200msくらいはフレームワークで持っていかれる感じです。通常のサイト表示での利用であれば200msくらいであれば気にならないのですが、今回はAPI的な感じで利用している部分です。結果が全部違うのでキャッシュにも乗っけられません。大量にアクセス前提なのでこの200msの時間はもったいなかったです。

APIではデータベースアクセスも発生しない単純処理が大多数でした。このAPI部分はフレームワークを捨てました。結果、5msとか10msくらいまで応答時間を短縮することができました。メモリの利用量も大幅に減らせたのです。

これが一番大きかったです。速度も早くなるし、サーバも減らせました。

 

・composerのautoloadの最適化

プロファイリングしているとcomposerのautoloadする部分が時間を使っていました。どうにも、最適化オプションが有る様子。

以下で最適化したautoloadのファイルが利用できて、少しだけ(50msとかくらい)早くなりました。

 

composer install --optimize-autoloader
か、インストール済みなら
composer dumpautoload -o

 

composer何度も使っているのですが、どんなに使い込んでもどうしても好きになれない。。。なんだかこれも気持ち悪いし。

 

▼ミドルウェアの見直し

php5.6からphp7.1へ。mysqlも5.6から5.7へ。OSのカーネルも4.6系へ。変更できる部分は全部変更しました。効果は不明。ほんの少し早くなったんじゃない?

 

 

というところで、かなり手を入れてまた愛着がわきましたとさ。サービスには愛着を持つのがとても重要ですね。

まだまだ効率化できそうな部分も多いので、もっといじくります。

megane

megane

最近、個人事業主から法人へと進化しました。 エンジニア歴13年位です。PHPとかMysqlを使ってWebシステムを構築します。 Javaも書きます。 CakePHPも使います。 サーバのチューニングもごりごりやります。 あと、お肉と自動車が好きです。Twitterとか申請どうぞ。

 - コピペチェック, 開発した , ,