Керенцева Марина Александровна

УДК 004.94+004.05

РАЗРАБОТКА ГРАФО-АНАЛИТИЧЕСКОЙ МОДЕЛИ УЧЕТА НАГРУЗОК ВЕБ-БАЗИРОВАННЫХ СИСТЕМ

Керенцева М.А., Мартыненко Т.В., Савкова Е.О.

Источник: Наукові праці Донецького національного технічного університету. Серія: «Обчислювальна техніка та автоматизація», Донецьк: 2010. – випуск 16(131).

Аннотация
Керенцева М. А., Мартыненко Т. В., Савкова Е. О. Разработка графо-аналитической модели учета нагрузок веб-базированных систем. Проанализированы принципы производительности и определены наиболее проблемные компоненты веб-базированных систем. Выполнен анализ типов нагрузки на веб-сервера и способов их оптимизации. Произведена классификация видов нагрузки на сервера по принадлежности к компонентам веб-системы. Для каждого класса предложены решения по снижению нагрузки. Разработана графо-аналитическая модель учета нагрузки веб-систем.
Ключевые слова: веб-базированная система, нагрузка, производительность, веб-сервер, веб-контейнер, база данных, граф, система нагрузочного тестирования.

Введение. В настоящее время все большее количество компаний и организаций начинают общаться со своими клиентами с помощью Web. Организация электронного документооборота предприятия включает:

1) отслеживание работы с архивными документами;

2) взаимодействие с клиентскими документами;

3) банковские системы управления счетами;

4) системы по организации бизнес-поездок;

5) управление бухгалтерией и др.

Крупные компании, филиалы которых часто распологаятся в разных городах, требуют реализации управления внутренними процессами организации посредством внедрения беб-систем. Для безотказной работы веб-системы необходимо прогнозировать ее максимальную производительность (количество запросов, обрабатываемых в единицу времени), при которой система выдерживает пиковые нагрузки. Нагрузка на веб-систему определяет время отклика на запросы клиентов, что является одним из основных показателей эффективности ее работы. В настоящее время существует два основных способа повышения быстродействия веб-системы [1, 2]:

1. Программный.
   • Разработка эффективных приложений для Web (быстродействие, используемые ресурсы)
   • Оптимизация и модернизация программных компонентов Web-сервера
   • Технология кэширования в среде Web
2. Аппаратный.
   • Увеличение полосы пропускания.
   • Установление высокопроизводительного сетевого оборудования
   • Использование системы балансировки нагрузки программных продуктов. Система балансировки программных продуктов подразумевает распределение нагрузки по нескольким серверам, что повышает отказоустойчивость Web-базированной системы.

Целью данной работы является определение наиболее проблемных компонентов и фрагментов веб-базированных систем на основе анализа их производительности.

Постановка задачи. Типичный процесс обслуживания запроса к веб-серверу предусматривает выполнение следующих шагов [3]:

1. Клиент инициирует запрос к серверу.
2. Браузер устанавливает соединение с сервером.
3. Веб-сервер создает новый поток/процесс для обработки запроса.
4. Если клиент запросил динамический контент (например, отправил запрос к скрипту), веб-сервер создает отдельный процесс или запускает модуль обработки. В результате обработки запроса формируется web-страница, которая отправляется клиенту.
5. Если клиент запросил статический файл, то сервер просто отправляет этот файл клиенту.
6. Браузер клиента получает ответ, закрывает соединение с сервером и отображает ответ.

На рис. 1 представлен процесс работы типичной Web-системы.

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

Предлагается представить обращение одного клиента к веб-системе в виде ориентированного взвешенного графа[4], где все пути являются простыми (рис.2).

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

Каждый переход характеризуется вектором из двух параметров:

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

Пример значений параметров приведен на рис. 2.

Рисунок 2 – Граф переходов запросов клиента веб-системы

Классификация времени загрузки веб-базированной системы. Со стороны серверной части взаимодействие с клиентом можно характеризовать следующей последовательностью действий [3]:
1) прием от клиента запросов во время сессии;
2) передача их при необходимости в другой код (возможно, с удаленным доступом), для обработки запроса и обращения к данным;
3) генерация результатов для отображения в браузере.

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

Рисунок 3 – Упрощенная схема web-соединения

На схеме процесс web-соединения разделен на ключевые операции, для обозначения которых предложен следующий классификатор:

Класс А – поступление запроса от клиента к веб-серверу или получение ответа.

Класс B – передача запроса/ответа между веб-сервером и веб-контейнером. сборка/разборка ответа/запроса веб-контейнером.

Класс С – передача разобранного запроса исполняющей программе, ее работа.

Класс D – обращения к базе данных (БД).

Каждая из указанных операций характеризуется набором параметров. Одним из основных параметров является время выполнения операции. Обозначим время выполнения операции для класса А: tA, для класса B – tB и т.д. Общее время перехода будет суммарным показателем выполнения всех операций:

(1)

(2)

где tвс – момент получения запроса (отправки ответа) веб-сервером;
tз – момент отправки запроса (получения ответа) клиентом.

(3)

где tк – момент отправки запроса в исполняющую процедуру (либо получения ответа от исполняющей процедуры);
t'вс – время получения ответа (отправки запроса) между веб-сервером и веб-контейнером.

Следует отметить, что знак выражения tк - t'вс определяется направлением операции (запрос или ответ), поэтому в (3) предагается использовать абсолютную величину времени выполнения.

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

(4)

где tD – суммарное время обращений к базе данных,
t'C – время работы исполняющей программы без обращений к базе данных.
С учетом (4), формулу (1) можно записать в виде:

(5)

Для снижения загрузки веб-базированной системы необходимо:
Этап 1. Определить критические переходы (рис. 2).
Этап 2. Выделить классы, требующие минимизации.
Этап 3. Выбрать средства снижения нагрузки.

Этап 1. Для реализации 1-го этапа необходимо выполнить моделирование множества обращений клиентов к веб-системе и определение наиболее критического перехода с максимальным временем выполнения, для чего предлагается использовать систему нагрузочного тестирования [5]. Для оценки всех показателей системы используется критерий Производительности (Performance) испытания, который представляет собой Нагрузочный (Load-testing) тест и тест Устойчивости (Stress). Тестирование заключается в имитации формирования запросов к веб-системе от нескольких тысяч посетителей с формированием кратковременных пиков нагрузки (в автоматическом режиме моделируется прохождение по ссылкам веб-системы одновременно многими виртуальными пользователями). Система нагрузочного тестирования выдает такие показатели как: время отклика системы, количество байт, участвовавших в транзакции, коды ответов сервера и т.п.

Для исследования одного пути на критичность используется отдельная группа потоков (Thread Group), в настройках которой задается выбранный сценарий. Каждое состояние системы (вершина графа на рис. 2) реализуется посредством добавления образца запроса (Sampler).

Введем показатель значимости j-го перехода µj (j = 0..k, где k – общее количество переходов)

(6)

Получив показатели значимости µj всех переходов по формуле (6), выбирается наиболее критический путем ранжирования вектора µ.

Этап 2. При определении класса, требующего минимизации (значение параметра max{tj}) производится тестирование выбранного критического перехода для получения средних значений времени перехода. При этом выполняемый сценарий будет состоять из одного образца запроса – того, который является конечным состоянием критического перехода.

Этап 3. Принятие решения по способу снижения нагрузки зависит от полученного на этапе 2 критического класса.

Для класса А используются аппаратные способы снижения нагрузки такие как: увеличение полосы пропускания, улучшение сетевого оборудования и т.д.

Для класса B решением может быть замена связки сервер-контейнер (аппаратное).

Для класса С – модификация программного кода и/или оптимизация структуры БД и работы ней.

Поскольку уменьшение значений tA и tB требуют внешнего вмешательства (что не всегда может быть достигнуто на практике), более детально рассмотрим снижение нагрузки для классов C и D. Для этого необходимо проделать шаги 1-3, но выполнять ранжирование временных показателей значимости µ с учетом только классов C и D. Таким образом:

(7)

Выделив таким образом «узкие места», необходимо принимать решения по снижению нагрузки:

• Модификация кода исполняющей программы.
• Использование или внедрение более эффективных серверных технологий.
• Оптимизация запросов к БД
  • Кэширование виджетов – полезных списков и ссылок, которые отображаются на каждой странице сайта. Информация в виджетах обновляется не так часто и ее можно кэшировать.
  • Составление списка активных запросов к базе. Запросы, время выполнения у которых самое большое, необходимо программно оптимизировать, либо кэшировать (если они еще не кэшированы).
  • Сокращение числа сложных запросов.
• Организация обращений к сессиям. Сессии являются файловым хранилищем (файлы сессий хранятся на жестком диске сервера), поэтому обращение к ним следует минимизировать.
• Формирование кластеров БД.
• Другие решения: специфичные для отдельно взятого типа базы данных и позволяющие снизить количество обращений к ней, улучшить функционирование и качество программных средств.

Литература:
1) ТАО ЧЖОУ «Системы балансировки нагрузки Web-серверов», Журнал "Windows 2000 Magazine", #03/2000.
2) Богомолов С.В., Спирягин В.И. «Создание структурно оптимальной системы управления веб-сайтом» [Электр. ресурс], Режим доступа к изд.: http://xpoint.ru/know-how/Articles/ModelCMS
3) James McGovern, Rahim Adatia, Yakov Fain. "Java™ 2 Enterprise Edition 1.4 Bible", Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevar Indianapolis, IN 46256.
4) Уилсон Р. Введение в теорию графов. Пер с англ. М.: Мир, 1977. 208с. [Электр. ресурс], Режим доступа к изд.: http://eqworld.ipmnet.ru/ru/library/books/Uilson1977ru.djvu
5) "Apache JMeter", Apache Software Foundation, URL: http://jakarta.apache.org/jmeter/