バイセル Tech Blog

バイセル Tech Blogは株式会社BuySellTechnologiesのエンジニア達が知見・発見を共有する技術ブログです。

新卒エンジニアがアプリケーションのパフォーマンスをチューニングした話

はじめまして、今年新卒として入社したテクノロジー開発部の酒井です。

 

 

自己紹介

そして4月に入社して自社在庫管理システムの開発を行う「AXIS」チームにバックエンドエンジニアとして配属されました。

私のバックグランドとしては今までバイトやインターンでの開発経験はなく、コードは大学で少し触れた程度です。

 

はじめに

AXISはリリースされてから約2年ほどがたち、リリースした当初より抱える在庫が増え、画面のロード時間の遅さが目立ってきました。

そこで今回APIのレスポンスを改善することに至りました。

 

方法

改善するあたり以下の手順で進めていきます。

  1. まずはどのAPIが遅いのかを調べる
  2. 遅くしている原因を突き止める

 

レスポンスタイムが最も遅いAPIを調べる

NewRelicとはパフォーマンス監視サービスです。サーバ/アプリケーションの
レスポンスや実行にかかった時間などの統計情報をNew Relicのサイトで確認できます。
 

f:id:bst-tech:20201222015308j:plain



 

遅くしている原因を突き止める

 今回は以下の2パターンを見ていきます。

・N+1

・発行するクエリ時間

N+1問題

N+1とは一対多のリレーションでSELECTする時に起こります。

f:id:bst-tech:20201207153045p:plain

 

しかしN+1問題が起きているかどうかは実際のクエリをみないといけない

bulletはN+1問題が起きている箇所をお知らせてくれる便利なgemです。

 

github.com

 

N+1問題解消するメソッドには以下があります。

  • preload
  • eager_load
  • includes
preload

IN句でまとめてJOINしたくないでかいテーブルを扱うときはpreloadを使う

eager_load

クエリの数が1個で済むので場合によってはpreloadより速い
JOINしているので、joinsと同じようにJOINしたテーブルで絞込ができる

includes

includesはIN句でまとめたり、JOINしたりとケースbyケースで処理が変わるので基本的にあまり使わない方がいい

 

f:id:bst-tech:20201207154310p:plain

発行するクエリ時間が遅い時

クエリの時間が遅い時indexが貼られていないことが多いです。

indexを貼って改善するかどうかはEXPLAIN ANALIZEを叩いてみるとわかります。

 

f:id:bst-tech:20201207152635p:plain

 

Nested Roopが起きている箇所にindexを貼ると以下のように結果が変わります。

f:id:bst-tech:20201207152719p:plain

 

まとめ

NewRelicやgem Bulletを使うことで誰でも簡単にAPIのチューニングすることができます。

 

バイセルテクノロジーズではエンジニアを募集しています。

もし興味をお持ちいただけましたらぜひご連絡下さい!