Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

パフォーマンスを改善するには仕様変更が1番はやい

 パフォーマンスを改善するには仕様変更が1番はやい

PHPerKaigi 2024の登壇資料です。

yamamoto-hiroya

March 07, 2024
Tweet

More Decks by yamamoto-hiroya

Other Decks in Technology

Transcript

  1. 自己紹介
 • やまもとひろや
 • NE株式会社 開発部マネージャー
 ◦ NE株式会社は本カンファレンスのシルバースポンサーです。
 ◦ 温泉の素を配っている会社です!


    ◦ エンジニア募集中ですのでご興味あれば声かけてください!
 • 旧twitter: @HiroyaYamamoto1
 • Qiita: @yamamoto_hiroya
 
 • 過去登壇
 • PHPerKaigi 2023
 ◦ 安全にプロセスを停止するためにシグナル制御を学ぼう!
 ◦ ベストフィードバッカー殿堂入り
 • PHP Conference Japan 2023
 ◦ プルリクサイズが大きいと警告してくれる君 を作りました!

  2. 検索画面を例にしたフローチャート
 仕様変更の
 余地があるか?
 検索条件にインデックス付与 
 同じ条件の場合は結果をキャッ シュ等
 YES
 NO
 その検索画面


    は必要か?
 検索画面を削除
 NO
 検索条件の変 更は可能か?
 即時で返す必 要はあるか?
 全件返す必要 はあるか?
 YES

  3. 実際に行った仕様変更を伴わないパフォーマンス改善例1
 • 問題のクエリ抜粋
 • WHERE A.id = B.id
 • A.idはVARCHAR型


    • B.idはINT型
 • それぞれにインデックスは付与されている。 
 • 型が異なっているためにインデックスが効かずにフルスキャンになっていた。 
 • 改善したクエリ抜粋
 • WHERE A.id = CAST(B.id AS CHAR CHARACTER SET utf8)
 • 型を揃えたことでインデックスが効いて爆速になった。 
 • 5時間かかっていたクエリが1秒以下になりました。

  4. 実際に行った仕様変更を伴うパフォーマンス改善例1
 • 改善後
 • 60秒かかっていた処理が5秒になりました。
 • 全てダブルクォートで囲むようにした( 仕様変更)
 • こうすることで条件分岐が不要となった。

    
 • また全てクエリで完結するようにすることでループ処理不要。 
 • 元々不要であった2倍のメモリ確保も不要。
 • 例えばこんな配列が返る
 • 後の処理を読んでいった結果CSVにしたいようで
 • カンマがある時だけ囲みたい、という仕様に意味はなかった 
 SELECT CONCAT('"', id, '","', name, '"') FROM Hoge;

  5. 実際に行った仕様変更を伴うパフォーマンス改善例2
 • 画面を開くと一旦全件一覧を表示する画面があった。 
 • レコード数が少ないうちはパッと一覧が見れて良かった。 
 • レコード数が多くなるにつれて画面を開くだけで重くなる症状となった。 


    • そこで初期表示を何もしないようにした。( 仕様変更)
 • そこから本当に見たいものを検索して絞り込みを行うことでパフォーマンスが改善された。 
 • ユーザー体験も良く、ただなんとなく開いただけでブラウザが重くなるとかそういった事故を防げ るようになった。
 • そもそも初期描画で全件検索結果表示が不要だった。 

  6. 実際に行った仕様変更を伴うパフォーマンス改善例3
 • 社内のツールの検索が重かった。 
 • 検索できる項目が多く全てにはインデックスが付与されていない。 
 • またレコード数も年々増えており下手な検索をするとサービスが落ちることもあった。 


    • デフォルト条件に「直近3ヶ月のレコード」をつけることで下手な検索を防ぐように変更を加えた。 (仕様変更)
 • どうしてもそれより前のデータが見たい場合は範囲を絞って上手に検索してもらうように運用して もらうこととした。
 スクショを撮ったのが 2024/02/02

  7. 実際に行った仕様変更を伴うパフォーマンス改善例4
 • これは実際まだ行えていないアイデアの段階。 
 • 部分一致検索を前方一致LIKEにするだけでもインデックス効くようになるのではやくなる。( 仕 様変更)
 ◦ インデックスは辞書みたいなものなのでcodeから始まっていることが分かれば途中まで辞書が引ける


    ◦ 前半は分からないがcodeで終わる、みたいなものは辞書が引けない
 • 日付の検索条件を足し、デフォルトで直近 1日とかにしておく。(仕様変更)
 • 日付にもインデックスが付与されているのでそこで絞り込めるようにしておく。 
 • 見たい履歴は直近のものだろうから良さそう。 
 ◦ ユーザーがこの画面に何を求めているか?
 ◦ ヒアリングや社内調整しつつ進める必要がある。
 ◦ エンジニアの「恐らくこうだろう」だけで進むのは危険。
 (前方一致)
 作成日
 2024/02/01
 LIKE “code%”

  8. まとめ
 • 本セッションでは「仕様変更」という選択肢もありきで考える「パフォーマンス改善」についてお話 しました。
 • 当然元の挙動を保たなければならないケースもあります。 
 • 大事なのは
 •

    「何故やらなければならないのか」 
 • 「何がその機能の価値なのか」
 • 「仕様変更の選択肢はありえるのか?」 
 • 既存処理に囚われることなく最適なパフォーマンス改善をしていきましょう!