Apache の接続失敗のトラブルシューティング

Apache の接続失敗のトラブルシューティング

Apache で発生する、奇妙で断続的な接続障害のトラブルシューティングを試みています。ホストしている Web アプリケーションの一部が動作していないというユーザーの苦情を受けて、この問題に気付きました。デバッグの結果、AJAX リクエストが JavaScript アプリケーションが期待する XML または JSON データを返していないことが判明しました。アプリケーションは SSL 経由で提供されています。

自分でテストしたところ、断続的に障害が発生し、Firebug には応答の長さがゼロであるか、接続が完全に失敗したように表示されました。Firebug が応答が空であると報告したときも含め、サーバーのアプリケーション ログには問題は表示されず、サーバーのアプリケーション ログにはデータが送信されたことが示されていました。

直感で apachebench ( ab) を起動したところ、接続エラーがいくつか見つかり驚きました。

[jnet@Stan ~]$ ab -v 1 -n 1000 -c 10 $url
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking workingman.smart-safe-secure.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.3
Server Hostname:        workingman.smart-safe-secure.com
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256

Document Path:          /
Document Length:        659 bytes

Concurrency Level:      10
Time taken for tests:   104.086 seconds
Complete requests:      1000
Failed requests:        2
   (Connect: 2, Receive: 0, Length: 0, Exceptions: 0)
Write errors:           0
Total transferred:      945000 bytes
HTML transferred:       659000 bytes
Requests per second:    9.61 [#/sec] (mean)
Time per request:       1040.855 [ms] (mean)
Time per request:       104.086 [ms] (mean, across all concurrent requests)
Transfer rate:          8.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      356  844 215.7    840    2268
Processing:    68  194 138.9    128    1483
Waiting:       67  178 122.0    116    1426
Total:        494 1039 241.8    993    2623

Percentage of the requests served within a certain time (ms)
  50%    993
  66%   1039
  75%   1101
  80%   1162
  90%   1407
  95%   1492
  98%   1626
  99%   1718
 100%   2623 (longest request)

これらのリクエストは静的 HTML ページに対するものなので、PHP アプリケーションが問題になっているわけではないようです。通常の HTTP (非 SSL) でテストを実行しても、エラーはまったく発生しませんでした。何が起こっているのかわかりません...ここからどのようにトラブルシューティングすればよいのかさえわかりません。httpd.conf 構成を喜んで投稿しますので、どの部分が役立つか教えてください。サーバーは Apache/2.2.3 (CentOS) で、mpm_worker と mod_fastcgi が搭載されています...

アップデート: 最初の AB テストで、同じ HTML ページに対して通常の HTTP 経由で 2 回の接続失敗が返されました。結局、SSL は問題ではないようです...

アップデート2: これは何らかのネットワークの問題である可能性があります。ab同じデータ センターのサーバーを使用してこれを複製することも、ablocalhost を使用してこれを複製することもできないためです。ただし、ワークステーションから問題のサーバーに ping を実行すると、パケット損失は 0% と表示されます... そのため、次にどのような手順を実行すればよいかわかりません。

アップデート3: 参考になれば幸いですが、abSSH トンネル経由でベンチマークを実行すると、失敗は発生しません...したがって、これは Apache の問題ではなく、ネットワークの問題である可能性があります...

答え1

リクエストが同じデータセンターで行われる場合や、SSH トンネルを使用する場合にうまく機能するとおっしゃっている場合、データセンターのリモート サイト間で何らかのシェーピングが行われている可能性があると思います。
たとえば、icmp や ssh (およびその他) が http よりも優先される場合などです。そのため、WAN が過負荷になると、ルーターが http トラフィックをドロップする可能性があります。一般的に、SSH は高い対話性を必要とするため優先されますが、FTP はファイル転送であるため優先順位が低くなります。
シェーピングまたは QOS が実施されているかどうか、ネットワーク チームに問い合わせてください。

もう 1 つ、問題は接続時間が 356 から 2268 であることにあると考えられます。356 は非常に遅いので、SSH でトンネルするとそれより短くなると思います。また、最小値と最大値の差が非常に大きいため、一部のパケットがドロップされ (QOS/シェーピングのため)、再送信が必要になる (そのため接続時間が遅くなる) と考えられます。

関連情報