Назад | Перейти на главную страницу

Keep-alive или not keep-alive

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 секунд.

Почему бы не установить таймаут поддержки активности, скажем, 15 секунд? Не вижу смысла держать каждое соединение по 2 минуты. И я не думаю, что браузер будет поддерживать соединение в течение 2 минут по этой ссылке: http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers, Таймаут в 1 минуту кажется более реалистичным.

Я бы посоветовал использовать очень низкие (1 с) таймауты активности.

если вы выполнили основную работу над перфомансом на стороне клиента (правильный порядок JS / CSS, JS внизу или асинхронно ...), вы можете установить очень низкий уровень активности (1 с), потому что не будет большой задержки между двумя повторными использованиями ваших TCP-соединений.

Если вы сомневаетесь, протестируйте свою страницу с помощью 5 и 1 (представление соединения), вы увидите, нарушает ли это повторное использование ваших TCP-соединений.

Я пробовал установить его на 0 в интерфейсе Apache, и это определенно слишком мало, но 1 в хорошем состоянии.