Определение факторов, влияющих на комплексную эффективность

На эффективность Web-транзакций оказывают влияние несколько факторов. Среди них пропускная способность соединения с конечным пользователем, наличие прокси-серверов на пути между клиентом и исходным сервером, потери пакетов в сети, а также нагрузка на исходный сервер. Объем доступных данных о местах происхождения запросов или характеристиках соединений клиентов с Internet достаточно ограничен.

В таблице 15.1 представлены некоторые компоненты, влияющие на эффективность Web. Таксономия не отражает фактических задержек, вносимых каждым из факторов. На эго есть две причины: отсутствие убедительных масштабных исследований и изменчивость, присущая любому большому исследованию комнлексной эффективности. Хотя проведение всестороннего исследования, которое учитывало бы все факторы, — непростая задача, можио начать с рассмотрения некоторых ключевых факторов, ограничив воздействие других. Кроме того, таблица не является исчерпывающей — в ней приведены не все факторы, которые могут оказывать влияние на суммарную задержку. В таблице сведены наиболее характерные источники задержки.

В первом столбце таблицы 15.1 представлены различные этапы Web-транзак- ции, начиная со щелчка мышью пользователем на гиперссылке в браузере до окончательного воспроизведения ответа браузером. Во втором столбце приведены примеры потенциальной изменчивости, которые могут повлиять на этап, приведенный в первом столбце (избежать его или осложнить его выполнение). Примером вариабельности является пропуск этапа преобразования доменного имени с помощью DNS, если IP-адрес сервера содержится в кэше DNS. Другой пример — дополнительные запросы на встроенные изображения после синтаксического анализа HTML-документа.

Таблица 15.1. Компоненты задержки

Этап Web-транзакции

Факторы, влияющие на задержку

Щелчок мышью в браузере Просмотр кэша браузера

Построение НТТР-запроса DNS-запрос на IP-адрес прокси-сервера

Перехватывающий прокси-сервер

TCP-соединение с прокси-сервером

Обращение/отсутствие обращения к кэшу DNS, быстродействие клиентского Компьютера

Версия протокола

Обращение к кэшу DNS, обращение к корневому серверу DNS

Быстродействие аннаратных средств/Группы прокси-серверов

Характеристики соединения с провайдером / долговременное соединение

Нагрузка на прокси-сервер/кэш

Иерархия кэшей

Доменное имя расположенного выше по потоку сервера

Обращение к следующему прокси-серверу в цепочке

ТСР-соединение с исходным сервером

UDP/ICP Обращение к DNS

Версии протоколов, задержка в сети

Наличие сервера-заместителя

Переадресация запроса сервером

Синтаксический анализ НТТР-запроса сервером

Нагрузка на сервер Создание ответа сервером

Соединение с новым сервером

Статический/динамический ресурс, задержка при выполнении CGI-сценария

Задержка на стороне сервера

Размер выходного буфера сокста

Синтаксический анализ и отображение ресурса браузером

Выдача дополнительных запросов

Рассмотрим типовую Web-транзакцию, которая начинается с выбора пользователем URL и заканчивается отображением ответа браузером. В главе 2 (раздел 2.3.1) мы обсуждали классический пример. Мы игнорировали потенциальное присутствие ряда других компонентов, таких как перехватывающие прокси-серверы, а также другие возможные действия, такие как переадресация запроса сервером. Мы также игнорировали особенности соединения с провайдером Internet и/или с Internet, а также потенциальные задержки, вызванные заторами в сети. Таблица 15.1 отражает попытку дать полную картину различных этапов Web-тран- закции. Щелчок мышью пользователем на гиперссылке приводит к обращению к кэшу браузера, чтобы проверить, доступен ли ресурс локально. Если нет, щелчок обусловливает НТТР-запрос.

Предположим, что пользователь соединился с провайдером для доступа к Internet. Соединение может быть низкоскоростным коммутируемым соединением, быстродействующим соединением с помощью кабельного модема или DSL. Сам провайдер может быть подключен к Internet через каналы, совместно используемые с другими провайдерами. Провайдеры могут использовать один или несколько прокси-серверов для различных целей, включая пересылку сообщений, совместное использование ресурсов и кэширование. Браузеры пользователей могут быть явно настроены на использование прокси-сервера провайдера.

Обращение к прокси-серверу на пути между клиентом и исходным сервером может быть настроено непосредственно на клиенте путем указания IP-адреса или доменного имени. Если пастройка прокси-сервера произведена указанием доменного имени (например, proxy01.aol.com), посылается DNS-запрос для получения IP-адреса прокси-сервера. Как говорилось в главе 5 (раздел 5.3.3), доменное имя прокси-сервера передается локальному DNS-серверу, который может иметь кэшированный ответ, в этом случае задержка минимальна. Если же нет, то придется обращаться к другим DNS-серверами, может пройти несколько секунд, прежде чем IP-адрес будет получен. В большинстве случаев такой DNS-запрос посылается только один раз, поскольку информация будет кэшироваться либо браузером, либо локальным DNS-сервером.

Даже если прокси-сервер явно не указан, запрос может быть перехвачен нере- хватывающим прокси-сервером (см. главу 11, раздел 11.10.2). Заметим, что браузер не осведомлен о таких перехватах. Если ответ пришел от одиого из кэширующих прокси-серверов, общее время ожидания может быть иебольшим. Если же ответ не был найден на кэширующем прокси-сервере на пути к исходному серверу, запрос должен быть отправлен выше по потоку.

Предположим, что осуществляется обращение к явно указанному в браузере прокси-серверу, который является частью иерархии кэшей. Прокси-сервер может обратиться к иерархии кэшей, если он не способен найти ресурс в своем кэше. Запрос к кэшу обычно представляет собой UDP-сообщение, посылаемое с использованием протокола Internet Cache Protocol (ICP) другим кэшам на том же уровне иерархии. Успешный ответ от одного из кэшей на данном уровне иерархии сохранит малое значение общей задержки. Однако если ответ от кэша на данном уровне иерархии не получен, запрос должен быть отправлен серверам, находящимся выше по потоку в направлении исходного сервера. Тиничиая задержка при проверке в иерархии кэшей Squid составляет несколько миллисекунд в предположении, что UDP-сообщения не были потеряны.

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

До сих нор мы обсуждали роль браузеров и прокси-серверов. Теперь мы рассмотрим роль, которую играет протокол HTTP применительно к соединениям и кэшированию. Если клиент уже установил долговременное соединение с прокси-сервером, новый запрос не требует преобразования доменного имени прокси-сервера или установления TCP-соединения. Предположим, что запрос не был удовлетворен из кэша браузера, ближайшим к пользователю прокси-сервером или каким-либо еще прокси-сервером из Группы прокси-серверов провайдера. В этом случае запрос должен быть отправлен расположенному выше по потоку серверу. При этом начинают играть роль характеристики соединения между сетыо провайдера и Internet. Дополнительным фактором являются задержки, обусловленные заторами в сети и потерями пакетов. Обычно задержки в сети не представляют проблемы при взаимодействии пользователя с ближайшим к нему прокси-сервером. Если запрос пересылается другому прокси-серверу, расположенному дальше от пользователя, начинают сказываться факторы, связанные с обращением к DNS и нагрузкой на расположенный выше по потоку прокси-сервер. Общая задержка между границей сети провайдера и конечным прокси-сервером (который может представлять собой сервер-заместитель перед исходным сервером) равиа сумме задержек между компонентами. Эта часть измерений (от границы сети провайдера до конечного прокси-сервера перед исходным сервером) склонна к большой изменчивости результатов, а исследования в этой области широко не проводились.

При поступлении запроса комплексу Web-серверов, где располагается исходный сервер, первым запрос может получить сервер-заместитель перед исходным сервером. Сервер-заместитель может поддерживать свой собственный кэш часто запрашиваемых ресурсов. Если ресурса в кэше нет, заместитель переадресует запрос соответствующему серверу согласно принятой стратегии выравнивания нагрузки. Заместитель или исходный сервер в зависимости от типа запроса могут решить переадресовать запрос на другой сайт. Такая переадресация может быть обусловлена выравниванием иагрузки, иаличием более подходящего зеркального сайта или тем, что ресурс был перемещен.

Если предположить, что ресурс не был перемещен и является доступным, то может быть сформирован ответ. Нагрузка на исходный сервер является важным фактором, способствующим возникновению задержки при генерировании ответа. Независимо от иагрузки на исходный сервер, обработка запроса может потребовать значительного времени в зависимости от действий, которые должны быть выполнены. Например, для формирования ответа может оказаться необходимым обращение к серверу баз данных, и сервер должен поддерживать соединение до завершения запроса к базе данных. Ответ сервера может ожидать очереди на отправку и, в конце коицов, достигает браузера после прохождения через различные промежуточные звенья. Только после этого браузер может начать сиитаксический анализа ответа. Синтаксический анализ и воспроизведение ответа — еще один фактор, влияющий на общее время ожидания. Воспроизведение ответа может потребовать выполнения сценариев JavaScript и взаимодействия с локальными подключаемыми модулями перед окончательным отображением ответа пользователю. Если в ответе имеются встроенные ресурсы, браузер должен также осуществить их загрузку. Эти встроенные ресурсы могут размещаться на сервере, отличном от исходного сервера. Если мы будем считать исходный сервер базовым сервером для документа-коптей- нера, доставку встроенных изображений или другого содержания, связанного с до- кументом-контейнером, например, рекламы, могут осуществлять альтернативные серверы.

Рост популярности исходных серверов, распространяющих содержание, размещенное на других компьютерах, должен приниматься во внимание любым исследованием комплексной эффективности. Причинами применения такой альтернативной стратегии доставки является снижение нагрузки на исходный сервер и потенциально более эффективная доставка содержания альтернативными серверами. Одновременно со снижением нагрузки, исходный сервер сохраняет соединения и обслуживает большее число пользователей. С точки зрения пользователя, изначальный запрос был сделан к исходному серверу, а все содержимое было доставлено с исходного сервера. Сети распространения содержания (см. главу 11, раздел 11.13) играют все более важную роль в Web.

Потеря пакетов может иметь различную степень влияния на общую задержку. Если был потерян DNS-запрос, повторная передача такого запроса может значительно увеличить время ожидания. Точно так же, потеря пакета SYN в процессе установки TCP-соединения может внести существенную дополнительную задержку, о чем говорилось в главе 8 (раздел 8.1.1). Другие виды потерь не столь важны.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100