Вопрос: Уменьшение очереди запросов Apache


В New Relic один из показателей, отображаемых как часть времени отклика приложения, - «Queue Request»:

Чтобы собирать время ожидания запроса, вы   необходимо отметить запрос HTTP с помощью   отметка времени при запуске очереди. [1]

Это делается путем добавления HTTP-заголовка в Apache httpd.conf:

RequestHeader set X-Request-Start "%t"

Новая религия упоминает, что:

Для ведома очереди запросов оператор сайта может предоставлять больше экземпляров приложений.

Однако мы видели, что добавление новых экземпляров приложения (т. Е. Веб-узлов) не влияет на время ожидания запроса - оно остается постоянным. Мы видим, что это измеряется примерно в 250 мс.

Какие факторы влияют на длину очереди запросов и как ее можно уменьшить?

[1] http://support.newrelic.com/help/kb/features/tracking-front-end-time


5
2018-06-07 01:46


Источник




Ответы:


Я думаю, что лучший способ сделать это - увеличить параметры «Ограничения сервера» и «Максимальные клиенты» в Apache Config

Это определяет, сколько потоков Apache может обрабатывать одновременно. Если у вас значение «Макс. Клиенты» 100, Apache может обрабатывать до 100 запросов одновременно.

Вероятно, стоит также отметить, что Apache хорош для небольших файлов (текст, может быть, CSS / JS и т. Д.), Но не так хорош в больших файлах, таких как изображения, видео, flash и т. Д. Это связано с тем, что каждый из них требует нового запроса (если вы используете Keep-alive, но это не улучшает его слишком). Поэтому, если у вас есть страница с 49 внешними ресурсами (всего 50 запросов), для загрузки требуется 1 секунда, а максимальным клиентам установлено значение 100, вы можете обрабатывать только два просмотра страниц за секунду до того, как запросы начнут ставиться в очередь.

Вы можете обойти это разными способами, попробуйте разгрузить свой контент на CDN (цена начинается от около $ 0,10 / ГБ, но если ваша передача данных высока, возможно, стоит связаться с Edgecast или Akami, поскольку их цена намного дешевле в навалом). Это означает, что вашему серверу не нужно беспокоиться о каких-либо статических ресурсах, необходимых для загрузки страницы, поэтому в нашем примере выше вы теперь просматриваете до 100 просмотров страниц за секунду до начала очередей запросов.

Если вы не хотите распространять CDN, я бы предложил получить два IP-адреса на вашем сервере и связать их с Apache и один с NGINX. NGINX - это высокопроизводительный сервер, способный обрабатывать в тысячи раз больше подключений, чем Apache, NGINX не использует очередь запросов, такую ​​как Apache, поскольку она не блокирует. К сожалению, у NGINX нет всех функций Apache, вы не можете, например, запускать PHP напрямую через NGINX без проксирования на Apache / FCGI / HipHop и т. Д.

Как дополнение к этому, в вашем вопросе вы скажете «веб-узлы», правильно ли я буду думать, что вы используете Apache в качестве промежуточного балансировщика нагрузки / прокси-сервера для этих узлов? Если это так, я предлагаю вам протестировать что-то вроде NGINX, Varnish, HAProxy и т. Д., Поскольку они намного лучше подходят для подобных действий и обработки одновременных подключений.

-
РЕДАКТИРОВАТЬ:
Я думал, что это может вас заинтересовать в отношении серверов LB с интерфейсом.
Мы использовали Apache в качестве интерфейса для проксирования до 16 узлов приложений, разделенных на два сервера. Прокси-сервер работал на четырехъядерном процессоре Intel Core i5 (поэтому отнюдь не под-спецификацией). Мы начали замечать параболическую связь между количеством запросов / секунд и временем отклика. Примерно в 2000 запросах в секунду загрузка ЦП начнется, и каждый ответ займет около 800 мс, а на 3000 р / с каждый ответ займет около 2 секунд. Мы переключились на NGINX, и мы достигли 5000 р / с, добавив только 50 мс к задержке, а загрузка процессора была в четверти от того, что было с Apache.
Очевидно, что это полностью зависит от вашей ситуации, того, что вы делаете, и каких ресурсов у вас есть, но я просто подумал, что дам вам взять ее на себя =)


7
2018-06-17 08:37



Увеличение ServerLimit и MaxClients не оказало никакого эффекта - общее время отклика оставалось неизменным, включая размер очереди. Мы уже используем CDN, и эти веб-узлы находятся за аппаратным балансиром нагрузки. - DavidM


Я должен задать очевидный вопрос: в документации указано, что вы должны использовать заголовок HTTP X-Queue-Start (или X-Queue-Time), но вы упомянули, что используете X-Request-Start. Вы добавляете правильный заголовок?


0
2018-06-23 04:06



Я думаю, что документы изменились с тех пор, как я это сделал. Они все еще не совсем понятны, что устанавливать и где. - DavidM