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

Apache2 на Linux - как отследить проблемы с производительностью

Я на какое-то время застрял на этой теме: как я могу получить более подробную информацию о том, где горит время отклика.

Моя проблема - это крайняя разница во времени ответа. Иногда серверу требуется 5 или 10 секунд для ответа (особенно для первого вызова). Firebug отмечает это время в основном как «ожидание». Когда я проверяю localhost / server-status (где также возникает эта задержка), большинство слотов заняты, но через полсекунды они снова свободны. Я с трудом могу представить, что существует так много скачков нагрузки, объясняющих такое поведение.

Еще одна странная вещь: есть запросы на 100K изображений JPG, которые иногда - в зависимости от статуса сервера - выполняются 1, 2 или даже 10 секунд (столбец Req). В то же время сценарии PHP, которые включают некоторую нагрузку на ЦП, обрабатываются за 100 мс или меньше (ну, другим также требуется 1 или 2 секунды). Запросы к другим (меньшим) изображениям GIF или PNG даже перечислены с временем 0 мс.

Вот где я застрял: Есть ли способ узнать, что занимает 10 секунд для отправки простого изображения JPG?

Спасибо за хорошие идеи!

-

Система: Я говорю о веб-сервере Apache 2 в Debian Linux (Sequeeze), который в основном предоставляет страницы и изображения с использованием сценариев PHP. Сервер работает на VPS у профессионального хостера в Германии. На сервере нет подкачки памяти (насколько я могу судить по статистике), и загрузка процессора не особенно высока (время безотказной работы сообщает значение около 3, которое может возрасти примерно до 32 при экстремальной нагрузке - я думаю, что это должно быть 8 -CPU система). Конечно, я никогда не могу быть уверен, что делают другие VPS на сервере.

Специальные настройки: Примечательно, что сервер отправляет все данные через SSL. Я дополнительно сократил время поддержания активности до 1 секунды, потому что пользователи обычно проводят очень много времени на каждой странице (30-60 секунд), и поддержание этих подключений после получения изображения (изображений) быстро исчерпает память сервера (или 2 ГБ я могу использовать на VPS). Из-за более крупных скриптов PHP типичный поток занимает 20 МБ ОЗУ. Поэтому имеется только 50 серверных слотов (MaxClient), из которых 35 поддерживают сохранение активности.

Материал: Я создал тестовую страницу (https://www.soscisurvey.de/example/?debug&password=demo), что наблюдается на сервере site24x7.com (обычно отвечает за 1,4 секунды, но регулярно бывают всплески до 20 или 30 секунд). Чтобы проверить результаты, я отправил его в Load Impact es: http://loadimpact.com/load-test/www.soscisurvey.de-35648bef3b84d3269e1fc7cb11bf1721

Вот где я застрял: есть ли способ узнать, что занимает 10 секунд, чтобы отправить простое изображение JPG?

Плагин TamperData для Firefox явно покажет вам, что вы загружаете с сервера и сколько времени занимает каждый элемент:

https://addons.mozilla.org/en-US/firefox/addon/tamper-data/

Однако у вас могут возникнуть и другие проблемы с повторным подключением DNS, если загрузка занимает 10 секунд.

Вы также можете проверить apachetop. Установите его на свой веб-сервер Apache. Я установил его на свой и время от времени проверяю. Он покажет вам страницы с наибольшей загрузкой:

http://www.howtogeek.com/howto/ubuntu/monitor-your-website-in-real-time-with-apachetop/

Добавляя это как ответ, а не просто комментарий, так как это оказалось

Проблема звучала как проблема задержки диска. Я думал, что это проблема, по нескольким причинам

  • Время отклика сильно варьировалось без каких-либо предупреждающих знаков от стандартных индикаторов нагрузки.
  • Размещено на VPS, которые часто перепродаются, и поддерживается дисками NAS / SAN
  • Другие попытки решить проблему оказались безуспешными.

Поскольку вы не контролируете оборудование, у вас есть ограниченные способы решения этой проблемы. Вы можете связаться с поставщиком, чтобы они попытались исправить это, использовать файловую систему с поддержкой RAM или кеш в памяти (с которым вы экспериментировали) или сменить поставщика.