パフォーマンスを改善するに は仕様変更が1番はやい
 NE株式会社
 やまもとひろや
 PHPerKaigi2024 登壇資料


先に注意
 ● 本スライドにはサンプルコードがいくつか登場しま す。
 ● 文字が小さく読みにくい場合があります。
 ● 気になる方はお手元でスライドを開いて視聴する ことをオススメします。


自己紹介
 ● やまもとひろや
 ● NE株式会社 開発部マネージャー
 ○ NE株式会社は本カンファレンスのシルバースポンサーです。
 ○ 温泉の素を配っている会社です！
 ○ エンジニア募集中ですのでご興味あれば声かけてください！
 ● 旧twitter: @HiroyaYamamoto1
 ● Qiita: @yamamoto_hiroya
 
 ● 過去登壇
 ● PHPerKaigi 2023
 ○ 安全にプロセスを停止するためにシグナル制御を学ぼう！
 ○ ベストフィードバッカー殿堂入り
 ● PHP Conference Japan 2023
 ○ プルリクサイズが大きいと警告してくれる君 を作りました！


一緒に働く仲間を募集しています！


〜ここから本編〜


本セッションで伝えたいことは
 タイトルが9割です！


パフォーマンスは「はやい」方がいい


元の挙動を変えることなく「はやく」できる ならそれもいい


元の挙動を変えてもいいなら
 やり方はいっぱいある


ただ「はやく」するのではなく
 本質的に「はやく」できるといいよね
 ↑
 これが本セッションで言いたいこと


目次
 ● 動機とターゲット
 ● 「パフォーマンス改善」とは
 ● 「仕様変更」とは
 ● パフォーマンス改善の勘所
 ● 実際に行った仕様変更を伴うパフォーマンス改善 
 ● まとめ


動機
 後輩くん
 先輩(私)
 ここの処理が重いので改善したいんですけどどうしたらいいですかね？ 
 こうしたらはやくなるような気がするんですがうまくいかなくて 


動機
 後輩くん
 先輩(私)
 ここの処理が重いので改善したいんですけどどうしたらいいですかね？ 
 こうしたらはやくなるような気がするんですがうまくいかなくて 
 ふむふむ、そもそもその処理はどう使われてるの？ 
 どうなってるとユーザーは嬉しいの？ 


動機
 後輩くん
 先輩(私)
 ここの処理が重いので改善したいんですけどどうしたらいいですかね？ 
 こうしたらはやくなるような気がするんですがうまくいかなくて 
 ふむふむ、そもそもその処理はどう使われてるの？ 
 どうなってるとユーザーは嬉しいの？ 
 hogehogeがfugafugaな感じで


動機
 後輩くん
 先輩(私)
 ここの処理が重いので改善したいんですけどどうしたらいいですかね？ 
 こうしたらはやくなるような気がするんですがうまくいかなくて 
 ふむふむ、そもそもその処理はどう使われてるの？ 
 どうなってるとユーザーは嬉しいの？ 
 hogehogeがfugafugaな感じで
 じゃあ仕様を変えてこうしたらどうかな？ 


動機
 後輩くん
 先輩(私)
 ここの処理が重いので改善したいんですけどどうしたらいいですかね？ 
 こうしたらはやくなるような気がするんですがうまくいかなくて 
 ふむふむ、そもそもその処理はどう使われてるの？ 
 どうなってるとユーザーは嬉しいの？ 
 hogehogeがfugafugaな感じで
 じゃあ仕様を変えてこうしたらどうかな？ 
 え？速度改善で仕様って変えていいんですか？ 


動機
 こんなやりとりをしたことがあります。 
 その後輩は「パフォーマンス改善」というタスクを握ってそれを解決しようとしていましたが、相談に のった結果仕様を変更することで結果的にパフォーマンス改善となりました。 
 「挙動や仕様を変えていい」っていう発想が念頭にないのはもったいないよなーと感じたのがキッカケ です。


ターゲット
 ● パフォーマンス改善に興味がある人 
 ● 「パフォーマンス改善」が「元の挙動を必ず保つ必要がある」と思っている人 
 ● 是非本セッションを聞いて考え方を持ち帰っていただき、自身が持っているサービスに活かして ください！


〜ここから定義〜


パフォーマンス改善とは
 ● 本セッションにおいては「ユーザーが操作をして、欲しい結果を得られるまでにかかる時間」の ことをパフォーマンスと呼ぶこととします。 
 ● 「スループット」「レスポンスタイム」も類似 
 ● いかにユーザーにストレスなく欲しい結果を返すかを改善する活動をパフォーマンス改善と呼 ぶこととします。


仕様変更とは
 ● 本セッションにおいては「ユーザーから見て元の挙動から変わっていること」を仕様変更と呼ぶ こととします。
 ● 内部ロジックを変更してはいるが最終的にユーザーから見える結果が変わらない場合は仕様 変更とは呼びません。


パフォーマンス改善フローチャート
 仕様変更の
 余地があるか？
 重い処理を改善したい 
 仕様から見直し
 何を価値として提供するか再検討 
 本セッションの領域
 仕様を変えずに改善 
 クエリチューニング等 
 まず取り掛かる前にこの発想に なること自体が非常に重要
 YES
 NO


検索画面を例にしたフローチャート
 仕様変更の
 余地があるか？
 検索条件にインデックス付与 
 同じ条件の場合は結果をキャッ シュ等
 YES
 NO
 その検索画面
 は必要か？
 検索画面を削除
 NO
 検索条件の変 更は可能か？
 即時で返す必 要はあるか？
 全件返す必要 はあるか？
 YES


〜ここから勘所〜


仕様変更を伴わないパフォーマンス改善の勘所
 ● クエリチューニング
 ● キャッシュ
 ● 同期・非同期
 ● このあたりはたくさんセッションがあるので自分が気になったやつを見れば良いです 
 ● キャッシュ化や非同期化に関しては厳密に言えば仕様変更かもしれません。 


仕様変更を伴うパフォーマンス改善の勘所
 ● 常に念頭に「そもそも」をつけて物事を考える。 
 ● そもそもこの処理は必要なんだろうか？ 
 ● そもそも何がしたい処理なんだろうか？ 
 ● 条件や件数を絞ることはできないんだろうか？ 
 ● 即時である必要があるんだろうか？ 


〜ここから実例集〜


実際に行った仕様変更を伴わないパフォーマンス改善例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秒以下になりました。


実際に行った仕様変更を伴うパフォーマンス改善例1
 ● 問題の重い処理例
 ● やりたいこととしてはある配列を画面に返す（恐らく CSVにする）
 ● カンマがある場合のみダブルクォートで囲む 
 ● 例えばこんな配列が返る
 レコード数分の ループ 2倍の メモリ確保

実際に行った仕様変更を伴うパフォーマンス改善例1
 ● 改善後
 ● 60秒かかっていた処理が5秒になりました。
 ● 全てダブルクォートで囲むようにした（ 仕様変更）
 ● こうすることで条件分岐が不要となった。 
 ● また全てクエリで完結するようにすることでループ処理不要。 
 ● 元々不要であった2倍のメモリ確保も不要。
 ● 例えばこんな配列が返る
 ● 後の処理を読んでいった結果CSVにしたいようで
 ● カンマがある時だけ囲みたい、という仕様に意味はなかった 
 SELECT CONCAT('"', id, '","', name, '"') FROM Hoge;


実際に行った仕様変更を伴うパフォーマンス改善例2
 ● 画面を開くと一旦全件一覧を表示する画面があった。 
 ● レコード数が少ないうちはパッと一覧が見れて良かった。 
 ● レコード数が多くなるにつれて画面を開くだけで重くなる症状となった。 
 ● そこで初期表示を何もしないようにした。（ 仕様変更）
 ● そこから本当に見たいものを検索して絞り込みを行うことでパフォーマンスが改善された。 
 ● ユーザー体験も良く、ただなんとなく開いただけでブラウザが重くなるとかそういった事故を防げ るようになった。
 ● そもそも初期描画で全件検索結果表示が不要だった。 


実際に行った仕様変更を伴うパフォーマンス改善例2
 私が担当したものではないです。 
 社内ツールであったこともありユーザーの声を直 接聞くことができた。
 提案も良いし、ユースケースがちゃんと分かって いるし良いパフォーマンス改善と言えますね！ 


実際に行った仕様変更を伴うパフォーマンス改善例3
 ● 社内のツールの検索が重かった。 
 ● 検索できる項目が多く全てにはインデックスが付与されていない。 
 ● またレコード数も年々増えており下手な検索をするとサービスが落ちることもあった。 
 ● デフォルト条件に「直近3ヶ月のレコード」をつけることで下手な検索を防ぐように変更を加えた。 （仕様変更）
 ● どうしてもそれより前のデータが見たい場合は範囲を絞って上手に検索してもらうように運用して もらうこととした。
 スクショを撮ったのが 2024/02/02


実際に行った仕様変更を伴うパフォーマンス改善例4
 ● 履歴の検索画面が重い。
 ● 店舗についてはインデックスが効いている。 
 ● 商品コード(部分一致)検索が前後方LIKE検索なのでインデックスが効かない。 
 ○ 例: 
 LIKE “%code%”


実際に行った仕様変更を伴うパフォーマンス改善例4
 ● これは実際まだ行えていないアイデアの段階。 
 ● 部分一致検索を前方一致LIKEにするだけでもインデックス効くようになるのではやくなる。（ 仕 様変更）
 ○ インデックスは辞書みたいなものなのでcodeから始まっていることが分かれば途中まで辞書が引ける
 ○ 前半は分からないがcodeで終わる、みたいなものは辞書が引けない
 ● 日付の検索条件を足し、デフォルトで直近 1日とかにしておく。（仕様変更）
 ● 日付にもインデックスが付与されているのでそこで絞り込めるようにしておく。 
 ● 見たい履歴は直近のものだろうから良さそう。 
 ○ ユーザーがこの画面に何を求めているか？
 ○ ヒアリングや社内調整しつつ進める必要がある。
 ○ エンジニアの「恐らくこうだろう」だけで進むのは危険。
 (前方一致)
 作成日
 2024/02/01
 LIKE “code%”


究極の話
 ● その重い処理、いらない説ない？ 
 ● どういう使われ方をしていて、ユーザーは何がしたい？ 
 ● やりたいことを考えたときに、別にその重い処理をする必要はないのでは？ 
 ● その処理・その機能がなくなることで全体のパフォーマンスが改善される、ということもあるかも しれません。


まとめ
 ● 本セッションでは「仕様変更」という選択肢もありきで考える「パフォーマンス改善」についてお話 しました。
 ● 当然元の挙動を保たなければならないケースもあります。 
 ● 大事なのは
 ● 「何故やらなければならないのか」 
 ● 「何がその機能の価値なのか」
 ● 「仕様変更の選択肢はありえるのか？」 
 ● 既存処理に囚われることなく最適なパフォーマンス改善をしていきましょう！ 


No content