Gatlingの結果に出る「premature close」とは？原因と対策
Gatlingのレポートで premature close が出る場合、これは端的に言うと、HTTPレスポンスを最後まで受け取り切る前に接続（TCP/SSL/HTTP）が相手都合で閉じられた状態です。途中でFIN/RSTが飛んだり、プロキシがupstreamを切ったりすると、Gatling側は「読み取り中に接続が終わった」と判断してKOになります。
よくある原因（多い順）
1) タイムアウトで切られている（プロキシ/LB/サーバ）
- Nginx / Apache / LB（ALBなど）の idle timeout / proxy_read_timeout が原因で切断されるパターン。
- 特徴：毎回ほぼ同じ経過秒数（30秒/60秒/120秒など）で発生しやすい。
対策：最大レスポンス時間＋余裕を見て、タイムアウト値を中継～上流で揃えます。
- Nginx：
proxy_read_timeout/proxy_send_timeout/keepalive_timeout - Apache（httpd）：
ProxyTimeout/Timeout/KeepAliveTimeout - Tomcat：
connectionTimeout/keepAliveTimeout - LB：idle timeout（ALB/ELB等の設定）
2) 高負荷でサーバが耐えられず切っている
- スレッド枯渇、キュー溢れ、接続上限、GC、OOM、アプリ再起動などで「処理しきれず切断」される。
- 特徴：同時接続やRPSを上げた瞬間から比率が増える／サーバのCPU・メモリ・GCが荒れる。
対策：
- 負荷は段階的ランプアップ（いきなり最大負荷にしない）
- サーバ側の上限を見直す
- Tomcat：
maxThreads/acceptCount/maxConnections - Apache MPM（event/worker）：
ServerLimit/MaxRequestWorkersなど - Nginx：
worker_processes/worker_connections/ upstream keepalive
- Tomcat：
- JVMならGCログ・ヒープ・スレッド数の監視（落ちていないか確認）
3) keep-alive（接続再利用）の整合性不一致
- 中継（Nginx/Apache）と上流（Tomcat）のkeep-alive寿命やidle timeoutが食い違うと、再利用時に切断が表面化します。
対策：keep-alive / idle timeoutを中継と上流で整合させ、upstream keepalive設定を適切に行います。
4) 負荷生成側（Gatling実行マシン）の資源不足
ulimit -n（FD上限）不足、エフェメラルポート枯渇、NIC/CPU飽和など。- 特徴：サーバは元気そうなのに、負荷生成側のソケット状況が怪しい。
対策：
ulimit -nを十分大きく（例：65535以上）- ソケット状況を確認：
ss -s、ss -tan（TIME-WAITが増えすぎていないか等） - 必要なら負荷生成を複数台に分散
まず最短で原因を特定するチェックポイント
- 発生タイミングが一定か？（例：いつも60秒前後）→ タイムアウト起因が濃厚
- サーバ/プロキシのログに同時刻の痕跡があるか？（upstream timeout / reset / broken pipe 等）
- 切断が誰から起きたか（FIN/RST）を追えるなら、短時間のパケットキャプチャやLBログで切り分けが早い
「出ないようにする」ための現実的な方針
原則として、premature closeは切っている側（サーバ/プロキシ/LB）の設定や限界が原因です。まずはそこを是正するのが本筋です。Gatling側でできることは、
- 負荷のかけ方を滑らかにする（ランプアップ/スロットリング）
- クライアント側タイムアウトや接続設定を、サーバ側と矛盾しない範囲に整える
- 負荷生成側の資源（FD/ポート/CPU）を十分に確保する
といった、再現性と安定性を上げる方向になります。
付録：確認コマンド例（Linux）
ulimit -n
ss -s
ss -tan state time-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
これらで、FD上限・ソケット統計・TIME-WAITの増加・エフェメラルポート範囲を把握できます。
コメント