☰

Устранение неполадок при неудачных соединениях Apache

tag-icon • tag-icon apache-2.2 ssl connection
Устранение неполадок при неудачных соединениях Apache

Я пытаюсь устранить некоторые странные, периодические сбои соединения с Apache. Я заметил проблему, когда пользователи жаловались, что части веб-приложения, которые мы размещаем, не работают. Отладка показала, что запросы AJAX не возвращали данные XML или JSON, которые ожидало приложение JavaScript. Приложение обслуживается через 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 только что вернул 2 сбоя соединения по обычному HTTP для той же HTML-страницы. Так что, похоже, проблема не в SSL...

ОБНОВЛЕНИЕ 2: Возможно, это какая-то проблема с сетью, потому что я не могу повторить это с помощью abна сервере в том же центре обработки данных, и я не могу повторить это с помощью abна локальном хосте. Однако пингование сервера с моей рабочей станции показывает 0% потери пакетов... Поэтому я не уверен, какие шаги предпринять дальше.

ОБНОВЛЕНИЕ 3: Если это поможет, если я запускаю abтест через SSH-туннель, то никаких сбоев не возникает... так что, возможно, это проблема сети, а не Apache...

решение1

Когда вы говорите, что это отлично работает, когда запросы выполняются в том же центре обработки данных или когда вы используете туннель ssh, я думаю, что это может быть своего рода шейпинг между вашим удаленным сайтом в центре обработки данных.
Например, если icmp и ssh (и другие) имеют больший приоритет, чем http. Поэтому, если WAN, например, перегружен, маршрутизатор может сбросить http-трафик. Обычно SSH имеет приоритет, потому что ему нужна высокая интерактивность, в то время как FTP имеет меньший приоритет, поскольку он передает файлы.
Спросите у своей сетевой команды, есть ли какой-либо шейпинг или QOS.

Еще одна вещь говорит мне, что проблема может быть в том, что время соединения составляет от 356 до 2268. 356 довольно медленно, я предполагаю, что при туннелировании с SSH оно меньше. И такая большая разница между min и max говорит мне, что некоторые пакеты, вероятно, отбрасываются (из-за QOS/Shaping) и требуются повторные передачи (поэтому время соединения увеличивается).

Связанный контент