Кременчугский национальный университет имени Михаила
Остроградского, Украина
Методика проведения эксперимента по анализу работы веб-приложений
В
ядре веб-приложений на базе Drupal
реализован набор функций (API) для работы со всеми необходимыми компонентами:
СУБД, формами, кэшем, учетными записями пользователей и их правами. Для
взаимодействия с СУБД используется абстрактный интерфейс DB API, ядро Drupal
оперирует ANSI-совместимым SQL для работы с БД, а структуры (таблицы) для БД
определяются программистом в массивах специального вида. При этом
преобразование определений таблиц и запросов под особенности конкретной СУБД
выполняется специальной библиотекой [1-2].
Измеряемые
параметры работы веб-приложения: 
– нагрузка по
процессору, 
– объемы
используемой оперативной памяти, 
- нагрузка по диску, 
– нагрузка на
канал связи (трафик), 
– ошибки
интерпретатора, 
– уровень
ошибок в коде, полученный с помощью статического анализа, 
- трафик базы
данных, 
– показатель
качества SQL запросов, 
– количество
подключений к базе данных.
Это
исследование направлено на решение задачи диагностирования аномалий в работе
веб-приложений при изменении вышеперечисленных параметров, с дальнейшей
локализацией аномалии. Учитывая ограничения на изменение исходного кода
клиентских веб-приложений, для анализа были использованы статистические данные
использования ресурсов, которые предоставлены хостинг-провайдером IT-Patrol
Inc. Для веб-приложений задействованных в эксперименте
было задействовано логирование ошибок интерпретатора, логирование доступа к
домену веб-сервера, показатели использования аппаратных ресурсов и включена
трассировка функций. Основной задачей при исследовании является установка
взаимосвязей влияния работы функциональных элементов на изменение
диагностических показателей, как качественных, так и количественных.
Экспериментальная модель анализа работы
веб-приложений. Для формирования интегральной
оценки работы функциональных элементов клиентских веб-приложений используется
таблица 1, состоящая из критериев, значения которых представлены в двоичном виде. Результатом оценки функции станет число в
двоичном виде учитывающее приоритет критериев (в зависимости от их расположения
в таблице). Такой подход позволяет сделать оценку более гибкой и адаптировать
оценивание согласно тарифным планам хостинг-провайдера. Данный подход следует использовать в случае,
если на тарифном плане для клиента есть ограничения на использование ресурсов
(лимиты), оценка будет формироваться с
их учетом. Итоговой оценкой станет
среднее арифметическое от показателей работы функции за исследуемый период.
|
Function name |
function1 |
function2 |
function3 |
function4 |
functionN |
|
|
CPU Usage |
Mysql CPU |
1 |
0 |
1 |
0 |
1 |
|
PHP CPU |
0 |
1 |
0 |
1 |
0 |
|
|
RAM |
1 |
1 |
1 |
1 |
1 |
|
|
Website bandwidth |
Out bandwidth |
1 |
1 |
1 |
1 |
1 |
|
In bandwidth |
1 |
0 |
1 |
0 |
1 |
|
|
MySql bandwidth |
Out bandwidth |
0 |
1 |
0 |
1 |
0 |
|
In bandwidth |
1 |
0 |
1 |
0 |
1 |
|
|
MySQL Queries |
Select |
1 |
1 |
1 |
1 |
1 |
|
Update |
1 |
1 |
1 |
1 |
1 |
|
|
Other |
1 |
1 |
1 |
1 |
1 |
|
|
Diskspace |
Filesystem diskspace |
1 |
1 |
1 |
1 |
1 |
|
MySQL Diskspace |
1 |
1 |
1 |
1 |
1 |
|
|
IO |
Read |
1 |
1 |
1 |
1 |
1 |
|
Write |
0 |
1 |
0 |
1 |
0 |
|
|
Hits |
PHP Hits |
1 |
1 |
1 |
1 |
1 |
|
File hits |
1 |
1 |
1 |
1 |
1 |
|
|
MySql Connections |
0 |
1 |
0 |
1 |
0 |
|
|
Error logs |
Fatal/ Syntax |
1 |
1 |
1 |
1 |
1 |
|
Notices |
1 |
1 |
1 |
1 |
1 |
|
Таблица 1. Формирование
интегральной оценки работы функциональных элементов относительно потребляемых
ресурсов
Для
структурного анализа веб-приложения и оценки работы функциональных элементов
производится трассировка функций. Учитывая иерархию (уровень вложенности),
показатели использования ресурсов функций агрегируются и классифицируются как
нагрузка от функционального элемента (модуля).
Исследуя
показатели надежности работы веб-приложения, в рамках эксперимента можно
определить основные состояния веб-приложения:
·
Рабочее состояние.
Ошибок нет.
·
Рабочее состояние. Есть
предупреждения от интерпретатора
·
Частично рабочее
состояние. Критические ошибки.
·
Не рабочее состояние.
Критическая ошибка.
В
основе оценки надежности кода лежат разработанные автором сигнатуры для статического
анализа (учитывающие архитектурные особенности веб-приложения). Весовые коэффициенты ошибок, в используемых
сигнатурах, модифицированы с учетом классификации ошибок интерпретатора:
Таблица 1. Цены на ресурсы сервера и весовые коэффициенты параметров
при формировании цены для клиентов облачных тарифных планов IT-Patrol Inc.
|
Параметр: |
CPU 100% usage for 1 hour |
Веб трафик for 1Gb |
MySQL Bandwidth for 1Gb |
Disk
space for
10Gb/hour |
MySQL
Disk space for
10Gb/hour |
PHP requests for 10000 requests |
File requests for 100000 requests |
|
Цена |
$
0.13 |
$0.02 |
$
0.01 |
$
0.01 |
$
0.05 |
$
0.01 |
$
0.04 |
|
Весовой коэф-фициент |
0,481481 |
0,074074 |
0,037037 |
0,037037 |
0,185185 |
0,037037 |
0,148148 |
С
учетом введенных обозначений экспериментальную модель детектирования аномалий в
работе веб-приложений можно представить следующим способом (1–6) –
экспериментальные коды состояний функциональных элементов веб-приложения:
1. 
2. 
3. 
4. 
5. 
6. 
Изменение
значений характеристик следующими символами:
- уменьшение
значения характеристики;
- увеличение
значения характеристики;
- отклонение
значения характеристики от эталонного в худшую сторону.
Описанная
логическая модель детектирования аномалий в работе веб-приложений не применима
ко всем веб-приложениям и требует дальнейшего усовершенствования и адаптации
для разных типов приложений. В данной работе она используется лишь для
иллюстрации предложенного подхода в анализе.
Литература:
1.
Скачков Д.А.
Исследование механизмов оптимизации времени отклика веб-приложений. – Наука,
техника и образование. – Москва, 2014. – №6. – С.23-25.
2.
Hein D. Simloid: Evolution
of Biped Walking Using Physical Simulation / D. Hein – Berlin, Institute of
Informatic, 2007. – 415 p.