Content Delivery Network и Domain Name System

Сети доставки содержания (англ. CDN) часто используются для уменьшения нагрузки на хостинг для веб-приложений и его каналов. В этом случае увеличение производительности достигается за счет распространения всех требуемых ресурсов по сети серверов. Близость к таким веб-серверам незамедлительно оборачивается увеличение скорости загрузки компонентов. Основной упор в таких сетях делают на максимальное уменьшение времени ping до сервера, что приводит к впечатляющим результатам с точки зрения производительности.

Некоторые крупные интернет-компании владеют своими сетями CDN, однако, гораздо дешевле использовать уже готовые решения, такие, как Akamai Technologies, Mirror Image Internet либо CDNetwork. Для стартапов или личных веб-сайтов стоимость услуг сетей CDN может оказаться непомерно высокой, но по мере того, как аудитория увеличивается и становится все более удаленной от вас, CDN просто необходимы для достижения быстрого отклика веб-страницы.

Ценовая структура Akamai основана на общем весе веб-страниц в Кб и числе пользовательских загрузок. Оптимизация самих веб-страниц может очень сильно сказаться на общей цене. Предположим, что один из клиентов такого сервиса платит приблизительно $8000 в месяц за домашнюю страницу в 320 Кб. Если бы над сайтом была проведена работа, которая бы уменьшила общий вес страницы на 25%, то ежемесячная оплата для клиента сократилась бы на $2000. В этом примере речь идет всего лишь просто о домашней странице. Уже для нее затраты на разработку окупятся с лихвой!

Подключаем CDN

CDN - это множество веб-серверов, распределенных географически для достижения максимальной скорости отдачи содержания клиенту. Сервер, который непосредственно будет отдавать файлы пользователю, выбирается на основании некоторых показателей. Например, выбирается сервер с наименьшим числом промежуточных запросов (англ. hop) до него либо с наименьшим временем отклика.

Использование CDN потребует лишь незначительных изменений (либо вообще таковых не потребует) кода, но повлечет значительное увеличение скорости загрузки самих веб- приложений, потому что на нее сильно влияет и то, насколько далеко пользователь находится от нашего сервера. Размещение файлов на нескольких серверах, разнесенными географически, сделает загрузку сайта быстрее с точки зрения пользователя. Но с чего бы начать?

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

80-90% времени загрузки страницы уходит на загрузку ее компонентов: картинок, CSS, скриптов, Flash и т.д. Вместо того, чтобы заниматься изменением архитектуры самого приложения, сначала стоит распределить статический контент. Это не только позволяет добиться значительного ускорения загрузки страницы, но также легко реализуется благодаря CDN.

Yahoo! и Google

Yahoo! обеспечивает выдачу YUI (Yahoo! User Interface) библиотек, используя распределенную систему северов по всему миру бесплатно. Это сервис обеспечивает:

1. gzip-сжатие (уменьшает размер файлов от 60% до 90%);
2. контроль за кэширующими заголовками;
3. распределенный хостинг файлов, основанный на географическом расположении клиента. Предоставляется на основе передовых компьютерных систем.

Аналогичный сервис сейчас предоставляет и Google для JavaScript-библиотек (в том числе, естественно, для всех дополнений от Google, таких, как автоматическая страница «Ничего не найдено» (ошибка 404), AJAX API для поиска или Google Maps).

Сети доставки содержания задумывались в качестве простого хостинга для картинок и больших (аудио-, видео-) файлов, но сейчас они обрабатывают и JavaScript с CSS. Использование кэширования и системы контроля версий в сочетании с распределением файлов по такой сети может привести к существенному приросту производительности.

Количество DNS-запросов

Система DNS устанавливает соответствие имен хостов их IP-адресам, точно так же, как телефонный справочник позволяет узнать номер человека по его имени. Когда вы набираете www.yahoo.com в адресной строке браузера, преобразователь DNS, к которому обратился браузер, возвращает IP-адрес узла. DNS-запрос имеет свою цену. Обычно требуется 20-120 миллисекунд, чтобы его выполнить и получить ответ (в российских реалиях это время обычно больше). Браузер вынужден ожидать завершения DNS-запроса, т.к. до этого момента он еще не может ничего загружать.

Для повышения быстродействия результаты DNS-запросов кэшируются. Это кэширование может происходить как на специальном сервере интернет-провайдера, так и на компьютере пользователя. Информация DNS сохраняется в системном кэше (в Windows за это отвечает служба «DNS Client Service»). Большинство браузеров имеет свой кэш, не зависящий от системного. Пока браузер хранит DNS-запись в своем кэше, он не обращается к операционной системе для DNS-преобразования.

Internet Explorer, по умолчанию, кэширует результаты DNS-запросов на 30 минут, как указано в переменной реестра DnsCacheTimeout. Firefox кэширует DNS-ответы на 1 минуту, что видно из установки network.dnsCacheExpiration.

Когда клиентский кэш очищается (как системный, так и у браузера), количество DNS- запросов возрастает до количества уникальных имен хостов на странице. А это включает в себя собственно адрес самой страницы, картинок, скриптов, CSS-, Flash-объектов и т.д. Уменьшение количества уникальных имен хостов уменьшает количество DNS-запросов.

Однако уменьшение количества уникальных хостов потенциально уменьшает количество параллельных загрузок компонентов страницы. В свете этого обстоятельства наилучшим выходом будет распределение загружаемых компонентов между 2-4 (но не более) уникальными хостами. Это является компромиссом между уменьшением количества DNS-запросов и сохранением неплохой параллельности при загрузке компонентов страницы.