eventosは毎月イベントの体験・価値向上に向けた様々な機能を追加している反面、まだまだ未熟なぴよぴよコードも残っています。

今回はそんなぴよぴよコードを立派な親鳥に成長させた一例として、eventosチケット機能における「管理コンソール画面でのチケット一覧表示」速度改善を行なった具体例をご紹介します。

 

今回の目次

  1. 経緯
  2. 原因調査
  3. 配列二重ループへの対策
  4. 改善結果

 

1.経緯

eventosの管理コンソール画面でチケットの登録件数が増加すると、一覧表示が重くなり画面が開けなくなるケースが発生。

一覧画面

 

2.原因調査

チケットの登録数が多くなるにつれて表示に時間が掛かる設計ではあるものの、数百のデータで表示までに30 – 40分のような時間が掛かる状態は想定外。ボトルネックがどこかを調査。
⇨Chromeの検証メニューの「Network」でフロント側（js）かサーバ側（API）かを検証し、APIの処理が圧倒的に重いことが判明したため、APIの処理の見直しを実施した。

chrome検証メニュー

 

該当箇所を処理シーケンス図に書き起こしたところ、二重ループが発生している箇所を検出

beforeの処理シーケンス

処理シーケンス図をみると、ユーザー情報が配列に格納されて、チケット情報のループの中で更にループ処理を実施していた。特にユーザー数が大きくなった場合、単純に線形時間掛かってしまっている処理だった。

例）10000個の配列の9999番目のデータのidを検索する場合、9999回ループを回して検索できる

 

3.配列二重ループへの対策

修正方針として、ユーザ情報を配列ではなく連想配列に格納するように変更。key:ユーザID / value: ユーザ情報

修正後のシーケンス図

 

4.改善結果

３の修正の結果、以下の通り速度が改善した。

■チケット一覧表示時：28秒 → 2.2秒
■チケット登録時　　：7秒 → 1.2秒

こういった問題は、改めてピックアップするとぴよぴよコードとわかりますが、毎日コーディングをしている中ではうっかり書いてしまいがち。

シンプルではありますが、サービスとして、ループ処理で対応する件数が多くなることが想定できる場合は、1回あたりの処理がどれくらいで完了するのかを必ず意識した設計・実装を行うようにしましょう。