こんにちは。システムエンジニアの篠原です。
昨年にかけて取り組んでいたプロジェクトも、リリースを控え、パフォーマンステストを実施しているところです。
このフェーズまで進んでくると、原因を掴むのに苦労したり、頭の痛い内容がよくよく障害に挙がってくるものです。
設計レベルでの問題であることも多いのですが、今回はコーディングレベルでの原因と対応方法を挙げてみたいと思います。
以前、ログファイルに書かれた内容は障害分析の要、ということで記事を執筆いたしましたが、
ログを出力することは、長ければ長いほどそれなりのパフォーマンスを犠牲にすることでもあります。
最近携わった案件では、長大なファイルの内容を1行1行デバッグログとして出力する処理が、
APIのリクエスト実行時間の5割に上っているというお粗末な結果を生んでいました。
ログ出力を繰り返し実施するような場合、ログ出力を適当に打ち止めする工夫を施したり、ログレベルを TRACE 等重要度の低いレベルに下げることも検討してみてください。
設計に絡んだ部分であるかもしれませんが、データの分布上、条件として絞り込みが強くなるものから順にif文を構築することによって、条件分岐の回数を減らすことができます。
特に、これがループ内での処理分岐条件であったり、条件次第でファイルI/OやSQL実行、API呼び出しの実行有無が異なる場合は重要です。
また、条件的に打ち止めできるループを無駄に回しているケースも意外に多かったりします。
もったいないですね。適宜 break したり打ち止める条件を追加したりするようにしましょう。
とあるデータ配列Aから重複を取り除いた配列Bを取得したい、といったとき、
無闇にループを回しているソースを見かけることがあります。
これはやめましょう。配列の中身が増えれば増えるほど、ループの処理が増えることになります。
最近のほとんどのプログラミング言語には、重複を除くためのデータ構造が用意されていると思います（Javascriptも、ES6で Set が新たに導入されています）。
これを用いる事で、要素の重複をハッシュを使った効率の良いアルゴリズムで検知することができるようです。
普段から計算量が少ないアルゴリズムを優先して採用するよう、心がけましょう。
新人さんのコードをレビューしたりすると、簡単にできるはずのロジックを難解なif文やfor文で構成していたりすることも多々見受けられます。
口を酸っぱくして指摘することもありますが、普段からよりシンプルでコンパクトな、効率のよいコードを記述できるよう、繰り返す中で徐々に慣れてほしいものです。
入会申込
ログイン
