Я пытаюсь устранить некоторые странные, периодические сбои подключения с помощью 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 на localhost. Однако проверка связи с рассматриваемым сервером с моей рабочей станции показывает 0% потери пакетов ... Поэтому я не уверен, что делать дальше.
ОБНОВЛЕНИЕ 3: Если это поможет, если я бегу ab для тестирования через туннель SSH я не получаю сбоев ... так что, возможно, это проблема с сетью, а не проблема с apache ...
Когда вы говорите, что он отлично работает, когда запросы выполняются в том же центре обработки данных или когда вы используете туннель ssh, я думаю, что это может быть своего рода формирование между вашим удаленным сайтом в центре обработки данных.
Например, если icmp и ssh (и другие) более приоритетны, чем http. Таким образом, если WAN становится перегруженным, маршрутизатор может отбросить HTTP-трафик. Обычно приоритет отдается SSH, потому что он требует высокой интерактивности, в то время как FTP имеет меньший приоритет при передаче файлов.
Спросите свою сетевую команду, есть ли там Shaping или QOS.
Другая вещь подсказывает мне, что проблема может заключаться в том, что время подключения составляет от 356 до 2268. 356 работает довольно медленно, я предполагаю, что при туннелировании с SSH оно меньше. и такая большая разница между min et max говорит мне, что некоторые пакеты, вероятно, отброшены (из-за QOS / Shaping) и необходимы повторная передача (поэтому время подключения медленнее)