Советы по максимизации запросов Nginx / сек?

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

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

Мой 2-гигабайтный сервер Ubuntu 10.04 Rackspace (не производственный компьютер) может обслуживать около 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, но изменение этих значений, похоже, не помогает или не вредит мне.

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

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

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

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

Вы злоупотребляете рабочими потоками 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 и т. Д., Не забудьте измерить использование системных ресурсов во время теста.

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

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

3. Во втором предположении, узким местом является процессор. В этом случае измерьте время запроса и разделите на него 1 и кратное количество ядер в вашей системе. Это даст количество запросов в секунду, которое может обработать nginx.