Конфигурация сервера / Важный параметр для 500Req/Second

Конфигурация сервера / Важный параметр для 500Req/Second

Я настраиваю сервер для использования в качестве сервера nginx для сайта с очень большим трафиком. Ожидается, что он будет получать трафик с большого количества IP-адресов одновременно. Ожидается, что он получит 500Req/Second с не менее чем 20 миллионами уникальных IP-адресов, подключающихся к нему.

Одна из проблем, которую я заметил на моем предыдущем сервере, была связана с iptables / ipconntrack. Я не знаю об этом поведении и был бы рад узнать, какие все параметры машины ubuntu / debian (32/64) бит мне следует настроить, чтобы получить максимальную производительность сервера. Я могу поставить много оперативной памяти на сервер, но критически важной задачей является время отклика. В идеале мы не хотим, чтобы какое-либо соединение зависало / истекало время ожидания / ожидало, и хотим максимально сократить общее время отклика.

решение1

Вам действительно нужен iptables? Если вы хотите получить столько производительности из одной коробки, я бы посоветовал просто удалить ее полностью. Если вы тщательно настроите машину, удалив все службы, кроме nginx, настроив SSH для прослушивания на непубличном интерфейсе (VPN, lan и т. д.), то вы, возможно, сможете обойтись без брандмауэра. Это, по крайней мере, избавит вас от одной проблемы.

Вы пытаетесь сделать это наодинвеб-сервер или несколько из них? Даже простой DNS round robin поможет вам распределить нагрузку на несколько разных машин. Вам определенно понадобится несколько серверов для надежности.

решение2

Этот вопрос довольно обширен. Мой лучший совет вам — сделать шаг назад и подумать, как вы собираетесь масштабировать свое приложение. Хотите ли вы масштабироваться вверх (несколько больших серверов) или вниз (множество маленьких серверов) или, возможно, скомбинировать их. Как только вы определитесь со своей стратегией масштабирования, вы также можете разработать стратегию HA вокруг этого.

Я очень сомневаюсь, что вы увидите 20 миллионов уникальных посетителей сразу после запуска сайта (просто чтобы дать вам некоторое представление: это вывело бы его как минимум в топ-200 сайтов).

Разработайте хороший план масштабирования в соответствии с трафиком и не работайте на пределе возможностей своих серверов, оставляйте запас на случай пиковых нагрузок и приобретайте новое оборудование по мере роста трафика.

Мы получаем эти вопросы время от времени. Хорошо думать о будущем, но не планируйте иметь инфраструктуру, которая сможет обрабатывать 20MM/60MM/100MM уникальных посетителей с самого начала, вы потратите деньги впустую и получите инфраструктуру, которая в основном простаивает без дела.

Теперь, чтобы ответить на ваш вопрос, мы в Stack Overflow (в настоящее время) используем iptable и запускаем модули conntrack на наших маршрутизаторах front-end без проблем. Я бы предложил разместить новый вопрос с подробностями о точной проблеме, которую вы видите при запуске iptables/*conntrack* под нагрузкой.

И напоследок немного полезного чтения

Как мы управляем S[OFU]/Stack Exchange
Блог о высокой масштабируемости

решение3

500 запросов в секунду — это не так уж много, если все, что вы делаете, это обслуживаете относительно небольшие статические файлы. С другой стороны, если они большие или сложные — например, основанные на сеансах или зависящие от БД — то это довольно большая нагрузка.

Рассмотрите возможность установки обратного прокси-сервера, например Varnish, перед этим решением, настроенного на использование пула malloc в качестве кэша. Правильно настроенный VCL позволит вам буферизировать большую часть сайта в памяти, что означает, что nginx должен будет обслуживать только несколько избранных битов. Также не забудьте установить noatime для файловой системы.

Связанный контент