Я создаю пакет аналитики, и в требованиях к проекту указано, что мне нужно поддерживать 1 миллиард обращений в день. Ага, «миллиард». Другими словами, выдерживается не менее 12 000 ударов в секунду, и желательно некоторое пространство для взрыва. Я знаю, что для этого мне понадобится несколько серверов, но я пытаюсь получить максимальную производительность от каждого узла, прежде чем «бросать на него больше оборудования».
Сейчас у меня завершена и хорошо оптимизирована часть отслеживания обращений. Я просто сохраняю запросы прямо в Redis (для последующей обработки с помощью Hadoop). Приложение представляет собой Python / Django с пулеметом для шлюза.
Мой сервер Rackspace Ubuntu 10.04 объемом 2 ГБ (не производственная машина) может обслуживать около 1200 статических файлов в секунду (при тестировании с использованием Apache AB для одного статического ресурса). Для сравнения: если я заменяю ссылку на статический файл своей ссылкой отслеживания, я все равно получаю около 600 запросов в секунду - я думаю, это означает, что мой трекер хорошо оптимизирован, потому что он всего в 2 раза медленнее, чем обслуживание того же статического ресурса. неоднократно.
Однако, когда я сравниваю с миллионами обращений, я замечаю несколько вещей:
Мои вопросы --
а. Похоже, я уже исчерпал этот сервер? Сравнима ли производительность 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
Рассчитать максимальное количество рабочих соединений легко, если вы знаете мощность вашей установки. Общая емкость / количество ядер - это максимальное количество рабочих подключений. Чтобы рассчитать общую емкость, есть несколько способов.
Если вам не подходит указанный выше метод, попробуйте следующие методы. Я делаю общие предположения, игнорируя оперативную память и ввод-вывод, они также будут учитываться, но они дадут вам отправные точки, и вы сможете вносить изменения оттуда.
Предполагая, что пропускная способность является узким местом, возьмите средний размер объекта, который обслуживает nginx, и разделите вашу пропускную способность на это, и вы получите максимальное поддерживаемое количество qps.
Согласно второму предположению, узким местом является ЦП. В этом случае измерьте время запроса и разделите 1 на него и умножьте на количество ядер в вашей системе. Это даст количество запросов в секунду, которые может обработать nginx.