Компромиссы при упреждающей выборке

Для упреждающей выборки характерно противоречие между снижением времени ожидания на стороне пользователя и увеличением нагрузки на сеть и компоненты Web. При достижении компромисса между этими двумя факторами следует учитывать следующее:

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

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

•          Какие компоненты осуществляют упреждающую выборку. Упреждающую выборку может выиолиять любой клиент. В случае упреждающей выборки

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

Одной из первых систем выборки с упреждением в HTTP, осуществляющих синтаксический анализ HTML-файлов и упреждающую выборку ресурсов на основе гиперссылок, была система Letizia [Lie95], о которой говорилось в главе 2 (раздел 2.8.2). В Letizia для отображения загруженного с упреждением содержания открывались дополнительные окна. Система допускала настройку, чтобы следовать гиперссылкам в этих документах с целью упреждающей выборки ресурсов, на которые указывают гиперссылки. Однако упреждающая выборка всех ресурсов, на которые указывают гиперссылки на странице, может обусловить слишком большую нагрузку. Применяя эвристическую процедуру, клиент может с упреждением выбрать первые несколько ссылок на странице в предположении, что они являются наиболее популярными. Возьмем Web-страницу, содержащую снисок URL, возвращенный поисковой системой. Пользователь, скорее всего, будет обращаться к элементам списка по порядку, поскольку поисковая система уже выполнила их ранжирование. Однако в некоторых случаях популярность URL может быть не связана с их расположением на странице.

Агент пользователя может оценить популярность URL на осиове предыдущих запросов. Например, Letizia отслеживает предпочтения пользователя и действия при просмотре страниц с целью определения, какие ресурсы выбрать с упреждением. В сравнении с агентами пользователя, прокси-сервер лучше может судить о популярности ресурсов, анализируя запросы групп клиентов. На основе анализа поведения пользователей прокси-сервер может определить, какие гипертекстовые ссылки наиболее популярны. При получении запроса на HTML-файл прокси-сервер может также осуществить упреждающую выборку популярных ресурсов, доступных на Web-странице. Однако прокси-сервер не будет Иметь достаточно данных о поведении пользователей, если только несколько клиентов не обратились в прошлом к HTML-файлу ЦК98]. Сервер обладает более полной информацией о поведении пользователей. Таким образом сервер может предоставить прокси-сер- веру рекомендации относительно того, какие ресурсы вероятнее всего будут запрошены в будущем, о чем говорилось ранее в разделе 13.2.

Вместо того чтобы отправлять прокси-серверу рекомендации, можно встраивать статистические данные о популярности ресурсов в HTML-файл. Например, гипертекстовая ссылка может содержать дополнительную информацию о вероятности того, что пользователь выберет эту ссылку после чтения содержимого страницы. Это требует изменения HTML-страницы и периодического обновления статистики для страницы. Подобные подходы наиболее эффективны для специфических приложений, таких как поисковые машины, но не для всех HTML-страниц. В некоторых случаях человек, создавший HTML-файл, может напрямую управлять упреждающей выборкой. Например, предположим, что в HTML-файле http://www.foo.com/index.html имеется гипертекстовая ссылка на HTML-файл http://www.foo.com/neat.html, содержащий встроенное изображение http://www.foo.com/pic.jpg. Наличие гиперссылки на pic.jpg на странице index.html приводит к тому, что клиент заранее выберет изображение при загрузке начальной Web-страницы. В результате изображение уже будет находиться в кэше клиента, когда пользователь запросит ресурс neat.html. чтобы не допустить вывода изображения вместе с первой страницей, можно указать для него небольшие размеры, например, один на один пиксел по ширине и высоте.

Большинство исследований, посвященных упреждающей выборке, основное внимание уделяют упреждающей выборке HTTP-ответов с сервера. Результаты этих исследований довольно разнородны. Снижение времени ожидания на стороне пользователя при упреждающей выборке можно снижать до тех пор, пока это не снижает производительности для других запросов. Однако выбранные с упреждением ресурсы, которые никогда не будут запрошены пользователем, способствуют значительному увеличению нагрузки на сеть и на сервер. Упреждающая выборка информации DNS, метаданных HTTP и установление ТСР-соединеиий не слишком увеличивает сетевой трафик. Однако упреждающая выборка информации DNS загружает DNS-серверы, а упреждающее создание TCP-соединений и упреждающая выборка метаданных HTTP загружает Web-серверы. В некоторых случаях упреждающая выборка метаданных HTTP через существующее ТСР-соединение может реально уменьшить нагрузку, поскольку в этом случае нет необходимости устанавливать отдельные TCP-соединения в будущем.

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

Резюме

В этой главе мы рассмотрели три направления исследований, связанных с кэшированием в Web. В первом разделе речь шла о проверке актуальности элемеитов кэша как важном факторе, обеспечивающем семантическую прозрачность при кэшировании. За счет технологии совмещения возможно уменьшить затраты на проверку актуальности, в то же время уменьшив время ожидания на стороне пользователя путем использования усовершенствованных алгоритмов проверки актуальности. Двунаправленный подход с применением фильтров и томов позволяет наиболее полно использовать информацию, доступную как прокси-серверам, так и исходным серверам. В результате удается оптимизировать выдачу рекомендаций прокси-серверам при минимальных затратах для исходного сервера и сети. Алгоритмы для построения томов — обширная область для дальнейших исследований. Изучение различных показателей эффективности позволяет строить алгоритмы для применения в различных ситуациях. Изучение упреждающей выборки на уровне DNS, TCP и HTTP раскрывает различные пути к снижению времени ожидания на стороне пользователя. Для каждого метода следует учитывать реальные затраты, которые будут иметь место в конкретной ситуации. При проведении исследований огромную роль играют фактические данные. Хотя обычно трудно получить достаточно большой массив данных, последние достижения в построении хранилищ данных (см. главу 14) могут способствовать тому, что рожденные в результате исследований идеи пройдут практическую проверку с использованием реальных данных измерений.

Источник: 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