Мы боролись с HAProxy уже несколько дней в Amazon EC2; опыт пока был замечательным, но мы застряли на том, чтобы выжать из программного балансировщика нагрузки больше производительности. Мы не совсем сетевики Linux (мы, как правило, являемся магазином .NET), но мы до сих пор придерживались своих собственных правил, пытаясь установить надлежащие ограничения, проверяя сообщения ядра и tcpdumps на предмет любых нарушений.
Тем не менее, пока мы достигли плато около 1700 запросов в секунду, и к этому моменту время ожидания клиента значительно (мы использовали и настраивали httperf для этой цели). Мы с коллегой слушали самый последний подкаст Stack Overflow, в котором основатели Reddit отмечают, что весь их сайт работает на одном узле HAProxy и что до сих пор он не стал узким местом. Ack! Либо как-то не видно столько одновременных запросов, мы делаем что-то ужасно неправильное, либо общая природа EC2 ограничивает сетевой стек экземпляра Ec2 (мы используем большой тип экземпляра). Учитывая тот факт, что Джоэл и основатели Reddit согласны с тем, что сеть, скорее всего, будет ограничивающим фактором, возможно ли, что это ограничение мы видим?
Любые мысли с благодарностью!
Редактировать Похоже, что на самом деле проблема была не с узлом балансировки нагрузки! В данном случае виновником были узлы, на которых выполнялся httperf. Поскольку httperf создает и разбирает сокет для каждого запроса, он тратит значительное количество процессорного времени в ядре. Когда мы увеличили частоту запросов, TCP FIN TTL (по умолчанию равный 60 с) слишком долго хранил сокеты, а значение по умолчанию для ip_local_port_range было слишком низким для этого сценария использования. По сути, после нескольких минут, когда клиентский узел (httperf) постоянно создает и уничтожает новые сокеты, количество неиспользуемых портов заканчивается, и последующие «запросы» ошибаются на этом этапе, что приводит к низким числам запросов / сек и большому количеству ошибок.
Мы также рассмотрели nginx, но мы работали с RighScale, и у них есть скрипты для HAProxy. О, и у нас слишком сжатые сроки [конечно], чтобы отключать компоненты, если это не окажется абсолютно необходимым. К счастью, нахождение в AWS позволяет нам протестировать другую настройку, используя nginx параллельно (если это гарантировано), и сделать переключение на ночь позже.
Эта страница довольно хорошо описывает каждую из переменных sysctl (в этом случае были настроены ip_local_port_range и tcp_fin_timeout).