こんにちは。
システムチーム/プログラマーのNです。
今月、先月と、弊社サービスの処理の高速化をタスクとして担当することがありました。
今回のブログは、対応するにあたり感じたことをブログにしようと思います。
まずは計測から
「推測するな、計測せよ」
という言葉がありますが、
まずは処理時間を計測し、数字にしてボトルネックになっている処理を見つけるところからスタートします。
「ここがネックになっているっぽいな」
と考えて、その処理だけ計測するのではなく、
初めから終わりまで全て数値化します。
１ 使用している言語ごと
２ データの取得ごと
３ データの整形ごと
４ 画面への出力
まずは範囲を大きくして計測し、細かい処理まで絞っていく感じです。
目的が明確
計測が終わり、原因がわかった段階で、どれくらい早くするかを宣言します。
極端にパフォーマンスが悪いところがある場合は、ネックとなる箇所を改善する範囲は限定的になりますが、
パフォーマンスに問題がない単体処理が続いて、結果的に遅くなっている場合があります。
その場合の難易度はかなり高いです。
無駄な処理を極限まで改善しても、結果が変わらない可能性があるからです。
ここで結果というのは
ユーザーが普通に使って違和感がないレベル
のことです。
サービスを使って早くなったと思うのは、開発者の考え。
ユーザーは使っていてそんなことを考えない。
快適なことは前提で、早い遅いを感じさせないことが重要です。
高速化を考えることで変わったこと
パフォーマンスチューニングをすることで、コードを書く際の考えが変わったと思います。
後々の負債になるか否かを前提に考えられるようになりました。
今はデータ量が少ないので問題ないが、データが増えるごとに極端にパフォーマンスが悪くなることはないか。
例えば、ログ関連のデータを保存するときは
どれだけの期間でどれだけ増えるのか。
データベースの保存先テーブルが違う場合は、取得するSQLの実行速度も遅くなっていきます。
さらに、保存先が違う場合、ソート処理は単純にSQLだけでは対応しきれません。
高速化を意識することでテーブルの構造にも注意を払う考え方が自然とできるようになりました。
根拠を持って処理を書くことができますし、
コード自体も無駄がない書き方に自然になる。
何より達成感を感じることが大きく、モチベーションが上がります。
タスク単位で考えることから、
システム単位で考えることが必須
だと感じたことが大きかったです。
これからも、この考えをベースに業務に臨みたいと思います。
