Мы делать много HTTP-запросов. Недавно мы начали думать об оптимизации на уровне ОС, чтобы делать больше запросов с одной машины.
Чтобы проверить производительность нашей ОС, я создал небольшой тест для сравнения на разных машинах. Тест использует curl -w как это:
#!/bin/bash
for (( ; ; ))
do
curl $URL -o /dev/null -s -w "SIZE: %{size_download} SPEED: %{speed_download} LOOKUP: %{time_namelookup} CONNECT: %{time_connect} START: %{time_starttransfer} TOTAL: %{time_total}\n"
done
Теперь я запустил его для одного URL. Результаты следующие: С моей локальной машины разработчика (подключенной к Fiber):
SPEED (b/sec) LOOKUP CONNECT START TOTAL
13,331.2481 0.0022 0.0228 0.2163 0.2175
На одном из наших производственных серверов (с виртуализацией XEN) результаты немного отличаются:
SPEED (b/sec) LOOKUP CONNECT START TOTAL
22,764.7700 0.0093 0.0455 0.1318 0.1334
И на другом несвязанном сервере, без виртуализации XEN (другой дата-центр, другой континент, дальше от ресурса)
SPEED (b/sec) LOOKUP CONNECT START TOTAL
32,821.3569 0.0004 0.0080 0.1608 0.1672
Как видите, производительность нашего производственного сервера далека от удовлетворительной. Скорость передачи данных выше, чем на моем локальном ноутбуке, но задержка убивает нас. Поскольку мы получаем ресурсы HTTP, размер которых довольно мал, мы необходимость чтобы оптимизировать эту задержку.
Есть идеи, с чего начать?
ОБНОВЛЕНИЕ: речь идет не о масштабировании веб-сервера. Речь идет о масштабировании веб-запросов.
Это хорошо изученная проблема («высокопроизводительное сканирование веб-сайтов») с множеством доступных исследований: http://scholar.google.com/scholar?q=web+crawling+performance ... да, я жульничаю, но, честно говоря, вы должны сначала полистать литературу.
Основываясь на моем собственном опыте построения систем такого типа в прошлом: вы не можете превзойти скорость света, поэтому так или иначе вы ее понесете. Что вы можете сделать, так это оптимизировать то, как и когда вы планируете выборку ресурсов. Например, у вас могут быть оптимизированные подсистемы для работы с частями проблемы - например, Разрешение DNS. Вы можете предварительно разрешить имена и подключиться напрямую к IP-адресу (просто добавьте правильный заголовок Host). После этого вам придется нести расходы на TCP-соединение, ни в коем случае. Тем не менее, если у вас есть несколько запросов к одному и тому же хосту, вы можете использовать это для сериализации нескольких запросов через существующее соединение: это помогает амортизировать затраты на установление связи TCP / TLS и дает вам лучшую сквозную производительность. Оттуда вам нужно продвигаться по лестнице протокола: иногда вы можете отслеживать цепочки перенаправления и запоминать последнее местоположение, чтобы пропустить дополнительные перенаправления в будущем (просто используйте запасной вариант). Фактически, то же самое применимо и к DNS. Вы можете реализовать оптимистичную стратегию и подключиться напрямую к IP, а затем использовать резервный вариант, если это не поможет. Для TLS вы можете хранить билеты сеанса и другие метаданные для более быстрого повторного подключения (то есть при условии, что вы повторно подключаетесь достаточно часто).
tl; dr: Я не добавляю здесь ничего нового, все вышеперечисленные советы (и многое другое) описаны в имеющихся исследованиях. Возьмите кофе, потратьте немного времени на чтение существующих статей!
Я не знаю, куда идут ваши HTTP-запросы, но вы могли видеть, поддерживают ли рассматриваемые веб-серверы SPDY.
Разработано в Google, SPDY это попытка конвейера нескольких запросов https для увеличения пропускной способности и уменьшения задержки.
Я также поддержу любые приведенные выше рекомендации по оптимизации DNS. Вы действительно хотите настроить DNS с кешированием, чтобы ускорить работу. Если у вас есть какой-либо контроль над TTL веб-сервера (ов), стоит увеличить их насколько вам удобно.