推測でチューニングしない ── 計測から始める作法
遅いという体感と、実際に時間を使っている場所は一致しません。何を、どの単位で測るか。平均を見てはいけない理由も含めて、改善に入る前の土台を整理します。
ボトルネックの見つけ方 ── レイヤーを切り分ける
遅い原因はアプリ・DB・ネットワーク・ディスクのどこかにあります。全部を同時に疑うと進まないので、症状から候補を絞る手順と、各レイヤーの見分け方を整理します。
SQL が遅い理由 10 パターンと直し方
遅いSQLの原因はパターン化できます。実行計画の読み方を押さえたうえで、現場で繰り返し出会う10種類を、症状・原因・直し方の形で並べます。
インデックス設計の判断軸 ── 貼るべき時と、貼ってはいけない時
索引は読み取りを速くする代わりに書き込みを遅くします。増やせば速くなるという話ではありません。何を基準に貼り、どう並べ、いつ剥がすかを整理します。
N+1 問題の見つけ方と、直さないという判断
一覧を取ってから1件ずつ関連データを引く構造は、開発時は速く、本番で破綻します。検出の仕組みと直し方、そして直さないほうがよい場合の見分け方を扱います。
キャッシュ戦略の選び方 ── 本体は「いつ捨てるか」の設計
キャッシュは速度と引き換えに整合性のリスクを買う仕組みです。どの層に置くかより、いつ捨てるかのほうが難しい。層ごとの性質と、無効化の方式を整理します。
バッチ処理を速くする ── 並列化の前にやること
並列化は最後の手段です。まとめる、減らす、やり直せるようにする。アムダールの法則が示すとおり、直列部分を削らないと並列化の効果は頭打ちになります。
フロントの体感速度 ── 数値と体感が食い違うとき
応答時間は改善したのに「遅い」と言われることがあります。人が感じる速さは、完了までの時間ではなく、待たされ方で決まるためです。その差を埋める考え方を扱います。
メモリと GC ── 遅さの正体が回収処理だったとき
処理は正しいのに、応答時間が不定期に跳ねる。原因がメモリの回収にあることがあります。言語を問わず共通する考え方と、リークの見つけ方を扱います。
負荷試験の設計 ── 意味のある試験と、意味のない試験
負荷をかけること自体は簡単です。難しいのは条件の再現で、そこを外すと「通ったのに本番で落ちる」試験になります。何を揃え、何を見るかを整理します。
「速くしない」という判断 ── 速度以外に失うもの
性能改善は必ず何かとの交換です。可読性、保守性、正しさ、開発速度。何を払うかを見ずに速さだけを追うと、後から高くつきます。やらない判断の基準を扱います。
チューニングのアンチパターン ── ここまでを裏側からまとめる
局所最適、過剰最適、再現性のない改善。よく見る失敗を10個に整理し、何を誤解しているのかと、どう戻すかをまとめます。連載の区切りとしての総括です。
まずは、現状を聞かせてください。
要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。