前回は、自分が所属しているチームで行っているテストについて書きました。
今回は自分が実装する際に気をつけている点と、性能改善で利用している New Relic と locustについて書きたいと思います。
実装で気をつけていること
一番気をつけていることは「ループの中でselectやcreateしているならループの外に出す」です。
select in で取ってくる、 bulk createする、これだけで結構レスポンスは改善されます。
アルゴリズムがどうとかそういうのはこれを取り除いてからしてます。
ツールの登場
どんだけ気をつけていても人間です。ついそのままにしているケースがあります。
New Relicで処理にかかっている時間を確認すると、同じselect文を何回も発行している状況を見ることができます。
それが見つかったならば1度で済むようにできないか検討・修正します。
New Relic
遅い処理は無いかな〜
このAPIの実行時間が約600msもかかっている!!
なんでだろ〜？
selectを71回も実行している!!
まずこんな感じで修正できそうなところを探して改善を試みます。
Locust
http://locust.io
Locustは負荷試験のツールです。New Relicで改善を行ったらlocustを使って負荷をかけ、APIのレスポンスを確認します。
そうするとロックの解放待ちでレスポンスが遅かったり、そもそも「デッドロック発生！」という結果が出て来るので、「じゃぁロックをかける範囲を狭くしよう」とか「ロックかける順番間違えてました！」なんてことが発覚し、更なる改善の手助けになりました。
それでも遅い、ということはあまりありませんでしたが、その場合はロジックを見直した方が良いということですね。
Why Locust?
わかりません！
自分、担当じゃなかったので！
この項目を書いている時はなんか駆け足でこの項目を通り過ぎようとしている感じです。
ただ、以前負荷試験をやることになりそうだったときにいじったJMeterと比較すると分かりやすかったです。
なぜかというと、pythonのコードで負荷試験が書かれてるから。
なんか自分でも書けそうだな、と思いました。
負荷試験のコードは実装経験がないので、後ほど勉強して投稿しますが、ヘビーユーザやライトユーザ用にアクセス人数を設定して、APIを叩く比率を設定して負荷をかけてる、ってことは分かりました（まぁJMeterもそういうことできると思いますが）。
ということで、次回のネタはLocustについて、にしたいと思います。