Назад | Перейти на главную страницу

Случайная задержка в Apache перед обслуживанием файлов

Я пытался устранить некоторые случайные задержки, которые случаются менее чем в 3% запросов, которые я отправляю на свой сервер. Я написал сценарий тестирования, который использует PHP file_get_contents на отдельном сервере и использует временные метки повсюду, чтобы определить, сколько времени занимает процесс. Я тестировал как статические файлы HTML, так и файлы PHP на обслуживающей стороне с одинаковым случайным лагом.

Моя проблема заключается в том, что случайным образом статическая страница, для восстановления которой требуется 0,1 секунды, занимает 3 секунды, а иногда и 5. В редких случаях это занимает 2 или 4 секунды.

Я исследовал все виды проблем, перечисленных ниже, но не могу определить причину. С помощью временных меток я определил, что задержка происходит еще до того, как apache обслуживает файл. Отметка времени в журнале apache соответствует началу файла и очень близка ко времени, когда я получил файл обратно в свой тестовый сценарий.

Мой тестовый скрипт отправляет 5 одновременных запросов на тестовую страницу, а затем запускает еще 5, когда завершит обработку этой команды.

Отставляющий сервер не имеет чрезмерной нагрузки во время выполнения сценария. ЦП отключен менее чем на 10%, а в памяти постоянно имеется как минимум 1 гигабайт. Процент запаздывающих нагрузок можно увеличить, увеличив количество одновременных подключений. Иногда во время расширенного теста страница полностью отбрасывается. Я протестировал 1 миллион страниц, и выпало только 10 страниц.

Единственный брандмауэр, который я не могу отключить, - это тот, который установлен в роутере. Это довольно хороший маршрутизатор с некоторыми встроенными средствами предотвращения атак DOS. Может ли количество запросов, поступающих с одного и того же IP-адреса, запускать протокол DOS, а маршрутизатор удерживает запрос?

Любые советы или вещи, на которые стоит взглянуть, будут оценены. Ниже приведены мои выводы и комментарии.

1) Поиск в DNS не выполняется. Я использовал netstat, чтобы посмотреть, чтобы подтвердить это. 2) Ресурсы сервера не исчерпаны. 3) Сценарий тестирования находится на другом сервере и в другой сети, нежели отстающий сервер. 4) Брандмауэры не должны быть проблемой. Тот же результат происходит при отключенном брандмауэре.
5) Я дурачился с конфигурациями apache, увеличивая максимальное количество клиентов и другие настройки. Ничто не помогло избавиться от проблемы. Если кто-то столкнулся с этой проблемой и у него есть конфигурация, которая, как они знают, помогает, я буду рад ее попробовать. 6) Я тестировал keep-alive и выключал без видимой разницы. 7) Я тестировал оба apache MPM, и произошла такая же задержка. 8) Значение% D в файле журнала apache не показывает увеличения для страницы, для обслуживания которой требуется 0,1 секунды, и для страницы, для которой требуется 3 секунды для загрузки.

Мне очень трудно поверить, что никто в Интернете не сталкивался с этой проблемой, но я искал уже 3 дня и не могу найти решение. Любая помощь будет принята с благодарностью. Спасибо.

В дополнение к вашему сценарию тестирования попробуйте также запустить приложение для тестирования производительности, например ApacheBench (ab) или Siege. Также запустите этот и свой тестовый сценарий на самом локальном сервере. Если проблема связана с маршрутизатором / сетью, ваши тесты на локальном сервере не должны показать никаких проблем. Вы можете поиграть с запросом параллелизма ab / siege, чтобы увидеть, возникает ли проблема чаще при более высоком параллелизме. Протестируйте его с различными файлами и типами файлов, чтобы увидеть, имеет ли это значение.

Ключ к устранению большинства неполадок - воспроизвести проблему, а затем сузить причину. Поскольку вы описываете это как «случайное», я бы постарался сосредоточиться на попытке воспроизвести проблему как можно более надежно. Если вы не можете воспроизвести проблему, вы действительно не узнаете, решите ли вы ее в конце концов или нет.

На самом деле может быть так, что «никто в Интернете не сталкивался с этой проблемой». Фактически существует бесконечное количество конфигураций оборудования / программного обеспечения / приложений, которые затрудняют диагностику некоторых проблем, подобных этой. Люди также могут использовать другое описание той же проблемы: то, что вы называете «случайной задержкой Apache», кто-то другой может назвать «проблемой производительности удаленного Ethernet».