Применение моделей рабочей нагрузки

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

Объединение параметров нагрузки

Создание синтезированного трафика включает в себя генерацию последовательностей псевдослучайных чисел с распределениями вероятностей каждого из параметров. Рассмотрим модель нагрузки, которая объединяет параметры и распределения, обсужденпые в двух предыдущих разделах и сведенные в таблицу 10.2. Начала пользовательских сеансов представляют собой Пуассоповский случайный процесс с некоторым средним зпачепием интервала между началами сеансов. Каждый новый сеанс начинается через некоторое время после начала предыдущего. Временной интервал между началами сеансов может быть получен с помощью случайного числа на отрезке от 0 до 1, соответствующего эксиопепциалыюму расаределению F(x). Это зпачепие, в свою очередь, может использоваться для вычисления Значения временного интервала x. Например, для экспоиепциалыюго распределения со средпим 1=1 и случайного числа 0.3679 получим зпачепиех=1 , т.к. e~’=0.3679. Повторяя эту процедуру, создаем последовательность чисел, определяющих времена пачал сеансов. Каждый сеаис состоит из некоторого числа переходов, которое может быть вычислено из распределения Парето. Каждый переход генерирует запрос Web-страницы, состоящей HTML-файла и некоторого числа встроенных ресурсов. После загрузки Web-страницы, задается некоторое время бездействия до следующего перехода; это время бездействия также вычисляется с помощью распределения Парето.

Таблица 10.2. Распределения вероятностей в моделях рабочей нагрузки Web

Распределение

Параметры нагрузки

Экспопепциалыюс

Интервалы между сеансами

Парето

Размеры ответов (хвост распределения) Размеры ресурсов (хвост распределения) Число встроенных страниц Время между двумя запросами

Логарифмически нормальное

Размеры ответов (тело распределения) Размеры ресурсов (тело распределения) Времснпая локализация

Зипфа

Популярность ресурса

Подобным образом могут быть сгенерированы и характеристики ресурса. Например, набор синтезированных Web-страниц может быть сгенерирован заранее и сохранен на сервере. Рассмотрим задачу создания 1000 Web-страниц для синтеза рабочей нагрузки Web-сервера. Раснределепие вероятности размеров HTML-pe- сурсов может быть использовано для определения размеров каждого из 1000 HTML-файлов. После этого можно использовать функцию распределения числа встроенных ресурсов для определения числа встроенных ресурсов для каждой из страниц. Размер каждого из встроенных ресурсов гакже определяется с помощью распределения вероятности. Каждый из эгих ресурсов будет иметь URL, который появится в HTTP-запросах, исходящих от Web-клиента. Далее, для определения доли клиентских запросов для каждого из ресурсов используется распределение Зипфа, описывающее популярность ресурса. Наконец, каждая Web-страница на сервере состоит из HTML-файла определенного размера и популярности, с которыми связано некоторое число встроенных ресурсов, каждый из которых имеет собственный размер.

Генерация синтезированной рабочей нагрузки требует объединения характеристик ресурсов со временем клиентских запросов. Например, запрос может быть связан с определенным URL с помощью распределения вероятности. Это дает уверенность в том, что клиент посещает каждую страницу в соответствии с ее популярностью. Однако это приближение не учитывает временной локализации последовательности запросов для одного и того же ресурса. Для того чтобы убедиться, что клиентские запросы соответствуют как распределению популярности, так и распределению временной локализации могут быть использованы дополнительные ириемы [BC98J. Другой важной проблемой является моделирование изменяющихся на сервере ресурсов, чтобы учесть воздействие измепепий в размере ресурсов в ре- алыюм трафике, прошедшем кэширование. Например, времена модификации ресурсов могут быть получены из распределения вероятностей. В каждый из моментов модификации ресурс может быть изменен на сервере. Дальнейшие запросы для этого URL будут требовать от сервера передачи ресурса, а не ответа 304 Not Modified.

Проверка достоверности модели рабочей нагрузки

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

Необходимость проверки достоверности модели возникает в большом числе случаев. Когда производительность системы оценивается с помощью синтезированной модели нагрузки или абстрактной модели системы, то достоверность результатов находится под сомнением. Однако модели редко подвергаются строгой проверке на достоверность. Такая проверка может быть трудной, длительной или просто невозможной. В других случаях модель, которая прошла проверку достоверности для некоторых приложений, ошибочно используется в другой ситуации. Обычно модель рабочей нагрузки конструируется для определенных целей, таких как оцепка производительности сервера и времени ожидания ответа пользователем. Может оказаться неподходящим использование одной и той же модели нагрузки для получения других метрик производительности, например, загрузки процессора сервера. Идеальпым было бы исследование каждой из основных метрик производительности с помощью реальной нагрузки. Тот же самый сервер может быть оцепеп и с помощью сиптезированной нагрузки, что облегчает прямое сравнение результатов измерений.

Модель синтезированной нагрузки используется также для тестирования серверов в различных ситуациях, которые могут случиться на практике. В этом случае сравнение с реальной нагрузкой может оказаться невозможным. Некоторые методики могут увеличить вероятность того, что синтетическая модель отражает реальные ситуации. Люди с опытом наблюдения Web-трафика могут испытать модель нагрузки, чтобы увидеть, учитывает ли она особенности реальной рабочей нагрузки. Анализ реального Web-трафика может помочь проверить заложенные в модель предположения. Например, предположим, что в модель рабочей нагрузки учитывает тот факт, что размер HTML-файла не зависит от числа и размеров встроенных в Web-страницу изображений. Анализ Web-измерепий позволяет определить, соответствуют ли предположения действительности. Кроме того, очепь важно исследо- ванпе чувствительности производительности системы к малым изменениям модели рабочей нагрузки. Если слабые изменения входных параметров оказывают существенное влияние на производительность системы, то это означает, что небольшие неточности в моделировании реалыюй рабочей нагрузки скомпрометируют используемую синтезированную модель.

Генерация синтезированного трафика

Приложение синтезированной нагрузки к прокси- или Web-cepвepy требует решения нескольких практических задач. Тестирование высокопроизводительного сервера требует создания высокоскоростного потока запросов от большого числа синтезированных клиентов, каждый из которых выдает запросы на основе модели нагрузки. Однако использование отдельного Компьютера для каждого клиента является дорогостоящей и труднореализуемой задачей. В идеале множество синтезированных клиентов Можно запустить на одном Компьютере [BC98, BD99J. Однако совместное использование ресурсов Компьютера может привести к возникновению корреляции между клиентами. Клиенты, заиущенные на одном Компьютере, будут конкурировать за доступ к процессору, оперативной памяти, дисковой подсистеме, а также за доступ к сети. Для предотвращения взаимодействия между синтезированными клиентами, число клиентов, приходящихся на один Компьютер, должпо быть ограничено и основываться на тестировании, определяющем момент, когда система не сможет обслуживать пи одного дополнительного клиента без искажения вида трафика. Поддержание большого числа клиентов на одном Компьютере требует наличия системы с большим объемом оперативной памяти и эффективной реализацией стека протоколов TCP/IP [BD99j.

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

Свойства сети также оказывают существенное влияние на производительность прокси- п Web-серверов. Internet проявляет высокую изменчивость в задержке пакетов п вероятностях их потерь, что влияет на управление скользящим окпом TCP. Реальная оценка производительности Web-cepnepa должна учитывать эти взаимодействия. Клиенты с высокоскоростным подключением непосредственно к серверу, будут создавать пагрузочпый трафик, существенно отличающийся от трафика клиентов, разбросанных по всему миру и имеющих пизкоскоростпые подключения. Нпзкоскоростпые подключения с большим временем ожидания ответов приводят к необходимости поддержания более длительных ТСР-соедипепий на сервере, что увеличивает число соединений, которые должпы обслуживаться одновременно. Кроме того, повторпые передачи утерянных пакетов, увеличивают объем данных, передаваемых сервером. Идеальное решеыие этой проблемы заключается в распределении сиптезнровапных клиентов в разных точках Internet. Однако на практике это может оказаться достаточно дорогостоящим решением. Альтернативой является направление клиентских запросов и ответов сервера через комиыогер, который эмулирует свойства сети, задерживая или теряя пакеты [BD99].

Производительность Web зависит от соотношений между пользовательским поведением, характеристиками ресурсов, загрузкой сервера и динамикой сети. Охватить все эти факторы в модели рабочей нагрузки на практике чрезвычайно трудно. Однако синтезированная модель нагрузки помогает оцепить и сравнить компоненты программного обеспечения Web контролируемым образом. Было ироведепо большое число экспериментов для сравнения различных реализаций прокси- и Web-серверов [Wbe, TS95, Spea, Pol, MCS98, AC98]. эти эксперименты используют набор клиентских и серверных программ для синтеза рабочей нагрузки, а также программ сбора и анализа данных. Обычно сиптезировапная нагрузка в этих экспериментах имеет стандартные параметры, задаваемые для создания одинаковой нагрузки при каждом их применении. С течением времени коммерческое программное обеспечение становится все более сложным, учитывающим все больше параметров нагрузки и новые особенности HTTP. Кроме того, тесты изменяются в направлении анализа других важных аспектов Web-графика, например, динамической генерации ресурсов и ответов об ошибках.

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