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

Советы по увеличению количества запросов Nginx в секунду?

Я создаю пакет аналитики, и в требованиях к проекту указано, что мне нужно поддерживать 1 миллиард обращений в день. Ага, «миллиард». Другими словами, выдерживается не менее 12 000 ударов в секунду, и желательно некоторое пространство для взрыва. Я знаю, что для этого мне понадобится несколько серверов, но я пытаюсь получить максимальную производительность от каждого узла, прежде чем «бросать на него больше оборудования».

Сейчас у меня завершена и хорошо оптимизирована часть отслеживания обращений. Я просто сохраняю запросы прямо в Redis (для последующей обработки с помощью Hadoop). Приложение представляет собой Python / Django с пулеметом для шлюза.

Мой сервер Rackspace Ubuntu 10.04 объемом 2 ГБ (не производственная машина) может обслуживать около 1200 статических файлов в секунду (при тестировании с использованием Apache AB для одного статического ресурса). Для сравнения: если я заменяю ссылку на статический файл своей ссылкой отслеживания, я все равно получаю около 600 запросов в секунду - я думаю, это означает, что мой трекер хорошо оптимизирован, потому что он всего в 2 раза медленнее, чем обслуживание того же статического ресурса. неоднократно.

Однако, когда я сравниваю с миллионами обращений, я замечаю несколько вещей:

  1. Никакого использования диска - это ожидается, потому что я отключил все журналы Nginx, а мой собственный код не делает ничего, кроме сохранения деталей запроса в Redis.
  2. Непостоянное использование памяти. Предположительно, из-за управления памятью Redis мое использование памяти будет постепенно расти, а затем снижаться, но это никогда не было моим узким местом.
  3. Загрузка системы колеблется в районе 2-4, система по-прежнему реагирует даже на самые тяжелые тесты, и я все еще могу просматривать вручную http://mysite.com/tracking/pixel с небольшой видимой задержкой, в то время как мой (другой) сервер выполняет 600 запросов в секунду.
  4. Если я провожу короткий тест, скажем, 50 000 обращений (занимает около 2 м), я получаю стабильные и надежные 600 запросов в секунду. Если я провожу более длительный тест (до сих пор пробовал до 3,5 м), моя частота вращения снижается примерно до 250.

Мои вопросы --

а. Похоже, я уже исчерпал этот сервер? Сравнима ли производительность nginx со статическими файлами 1200 / с с тем, что было у других?

б. Существуют ли общие настройки nginx для таких массовых приложений? У меня рабочие потоки установлены на 64, а рабочие потоки Gunicorn установлены на 8, но настройка этих значений, похоже, не очень помогает и не вредит мне.

c. Существуют ли какие-либо настройки уровня Linux, которые могут ограничивать мои входящие подключения?

d. Что могло привести к снижению моей производительности до 250 об / с при длительных тестах? Опять же, во время этих тестов память не исчерпывается, а использование жесткого диска равно нулю.

Заранее спасибо всем :)

РЕДАКТИРОВАТЬ Вот моя конфигурация nginx - http://pastie.org/1450749 - это в основном ваниль, с явно убранным жиром.

Вы злоупотребляете worker_threads Nginx. Совершенно нет необходимости запускать такое количество рабочих. Вы должны запустить столько рабочих, сколько у вас есть процессоров, и считать это днем. Если вы запускаете gunicorn на одном сервере, вам, вероятно, следует ограничить количество рабочих nginx двумя. В противном случае вы просто перегружаете процессоры переключением контекста, необходимым для управления всеми этими процессами.

Я использовал nginx для обработки запросов 5K в секунду для статического контента. Вы можете увеличить количество worker_connections, которое в настоящее время установлено на 1024.

Расчет max_client будет следующим.

Worker_connections и worker_proceses из основного раздела позволяют рассчитать значение maxclients:

max_clients = worker_processes * worker_connections

В ситуации обратного прокси max_clients становится

max_clients = worker_processes * worker_connections / 4

http://wiki.nginx.org/EventsModule#worker_connections

Рассчитать максимальное количество рабочих соединений легко, если вы знаете мощность вашей установки. Общая емкость / количество ядер - это максимальное количество рабочих подключений. Чтобы рассчитать общую емкость, есть несколько способов.

  1. Я бы посоветовал вам попробовать протестировать свою установку, чтобы получить наиболее реалистичные цифры. Вы можете использовать такие инструменты, как siege, pummel, apache bench и т. Д., Не забудьте измерить использование системных ресурсов во время теста.

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

  1. Предполагая, что пропускная способность является узким местом, возьмите средний размер объекта, который обслуживает nginx, и разделите вашу пропускную способность на это, и вы получите максимальное поддерживаемое количество qps.

  2. Согласно второму предположению, узким местом является ЦП. В этом случае измерьте время запроса и разделите 1 на него и умножьте на количество ядер в вашей системе. Это даст количество запросов в секунду, которые может обработать nginx.