Поддерживать или не поддерживать

Моя компания запускает новый веб-сайт с потенциально большими волнами посетителей в очень коротких окнах (оценка составляет около 14 тыс. Посетителей за 2 минуты).

Итак, я проверяю нашу конфигурацию, и сейчас моей самой большой проблемой является наш HTTP-интерфейс с одним узлом, который использует keep-alive. Интерфейс работает под управлением lighttpd 1.4 на CentOS 5.4.

Некоторые предположения:

• браузер обычно открывает 6 параллельных TCP-соединений для поддержания активности
• браузер будет держать соединение открытым, пока не истечет тайм-аут, даже если вкладка закрыта (наблюдается в FF, может не соответствовать действительности для каждого браузера)
• на стороне сервера каждое соединение будет потреблять ~150 КБ памяти в ядре (я использую conntrack и хочу сохранить его, это правильная оценка?)
• Все наши серверы размещены на восточном побережье. RTT с сервера в Лас-Вегасе составляет около 80 мс.
• Домашняя страница с keep-alive использует ~25 TCP-соединений и 1500 пакетов. Без поддержки активности это число возрастает до ~210 соединений TCP и более 3200 пакетов.

Итак, 6*14000 = 84 000 TCP-соединений. 84 000 * 150 КБ ~= 12 ГБ памяти. Вот проблема: 1. У меня нет такого объема памяти, доступного на внешнем интерфейсе. 2. lighttpd 1.4 не очень удобен для управления таким количеством подключений. это больно ударил / много.

Но с другой стороны, меня беспокоит 80 мс RTT, если я деактивирую keepalive.

Я собираюсь смягчить некоторые из этих проблем с CDN и вторичной записью www со вторичным lighttpd. но дебаты касаются функции поддержания жизни. Я хотел бы отключить его, но я боюсь, что влияние на время открытия страницы будет высоким (высокий RTT и удвоение количества пакетов).

После завершения поиска контента у нас есть много запросов Ajax для просмотра сайта, которые обычно вписываются в одно соединение TCP. Но я не уверен, что браузер освободит другие соединения и просто оставит их открытыми.

Я знаю, что было много дискуссий о поддержании жизни, потребляющих много ресурсов. Я с этим согласен, но, учитывая предположения и ситуацию (RTT между 80 мс и 100 мс для половины наших пользователей), как вы думаете, разумно ли это деактивировать?

В качестве побочного вопроса: знаете ли вы, где я могу найти информацию о размере соединения и размере conntrack в ядре? (кроме printf size_of (sk_buff)).

--- edit: некоторые результаты теста Я настроил conntrack на прием 500 тыс. соединений (учитывая объем памяти, который не должен превышать 200 МБ) и запуска тест ab.

ab -n 20000 -c 20000 -k http://website.com/banner.jpg

Из того, что я видел в tcpdump, ab устанавливает все соединения перед выполнением GET. Таким образом, я получаю представление о том, сколько памяти потребляется этими 20k-соединениями.

плита возвращается

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 40586  40586 100%    0.30K   3122       13     12488K ip_conntrack

и верх

 PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP CODE DATA COMMAND
 15   0  862m 786m  780 S 22.9  3.3   1:44.86  76m  172 786m lighttpd

12 МБ для ip_conntrack и 786 МБ для lighttpd в порядке для моей установки. Я могу легко справиться с этим в 4 раза.

Таким образом, keepalive, то есть, время ожидания простоя установлено на 5 секунд.