レイテンシ (Latency)
リクエスト送信からレスポンス受信までの時間。ユーザーが「遅い」と感じる直接的な指標です。
ボトルネックの特定・Webサーバー設定・DBクエリ改善・キャッシュ戦略まで、アニメーション図解と仮想コンソール演習で体系的に学べます。
▶ 遅いリクエスト → ボトルネック特定 → 最適化 フロー(アニメーション)
リクエスト送信からレスポンス受信までの時間。ユーザーが「遅い」と感じる直接的な指標です。
単位時間あたりの処理量(req/s)。システムの容量とスケール性を測る指標。
最初の1バイトが届くまでの時間。サーバー処理時間+ネットワーク遅延の合計。
遅い側5%/1%のレスポンス時間。平均値では見えない劣化を捉える重要指標。
▶ レイヤー別ボトルネック探索(アニメーション)
| ツール | 計測対象 | 危険ライン | 確認のポイント |
|---|---|---|---|
| top / htop | CPU使用率 | 80%以上が持続 | プロセスごとのCPU消費を確認。sysCPUが高ければカーネル側、userが高ければアプリ側。 |
| free -m / vmstat | メモリ使用量 | swap使用量が増加 | available が少なくswapが増え始めたらメモリ不足。OOMキラー発動の前兆。 |
| iostat -x 1 | ディスクI/O | await > 20ms, %util > 90% | ディスク応答時間と使用率。DB書き込みが重いときに顕著。 |
| ss -tlnp / netstat | ネットワーク接続 | TIME_WAIT大量蓄積 | 接続数と状態を確認。keepalive未設定だと接続の生成/破棄コストが高い。 |
| curl -w '%{time_total}' | レスポンス時間 | TTFB > 500ms | 外部から見た応答時間。内部計測と乖離があればネットワーク/プロキシに原因。 |
▶ 同時接続処理 — チューニング前後比較(アニメーション)
同時接続数の上限を引き上げ。workerプロセス数 × connectionsが最大同時接続。
512 (デフォルト)
1024-4096
CPU数に合わせてワーカーを増やし、並列処理能力を向上。メモリとのバランスに注意。
1 worker
2×CPU+1
転送量を60-80%削減。CPU負荷は微増だがネットワーク改善が大きい。
無効
text/html, application/json, css, js
TCP接続を再利用して接続確立コスト(3-way handshake)を削減。
無効
keepalive_timeout 75s
ブラウザキャッシュにより2回目以降のロードが劇的に高速化。
毎回転送
expires 30d + Cache-Control
▶ Seq Scan vs Index Scan — クエリ実行パス比較(アニメーション)
クエリの実行計画を確認。Seq Scan(全件走査)がボトルネックになっていないかチェック。
WHERE/JOIN/ORDER BYに使うカラムにインデックスを作成。複合インデックスの順序に注意。
pgbouncer等で接続を再利用。毎回新規接続だとオーバーヘッドが大きい(特にSSL時)。
select_related/prefetch_related(Django)で関連データを一括取得。100回のクエリが1-2回に。
log_min_duration_statement = 200ms で遅いクエリを自動記録。改善対象の発見に必須。
▶ キャッシュ HIT / MISS フロー(アニメーション)
| レイヤー | ツール | TTL目安 | 効果 |
|---|---|---|---|
| ブラウザキャッシュ | Cache-Control, ETag | 静的: 30日, API: 0 | 最も高速。サーバーへのリクエスト自体が発生しない。 |
| CDNキャッシュ | Cloudflare, CloudFront | 1時間〜1日 | 世界中のエッジでレスポンスを返却。オリジンサーバー負荷を大幅削減。 |
| アプリケーションキャッシュ | Redis, Memcached | 60秒〜5分 | DB問い合わせ結果をメモリに保持。読み取り多い画面で効果大。 |
| DBクエリキャッシュ | pg_stat_statements | クエリプラン | 実行計画のキャッシュでプランニングコストを削減。 |
演習を選び、次のコマンド実行を押すと疑似ログが流れます。数値の変化を確認してください。