Разделы портала

Онлайн-тренинги

.
Анализ Web-логов для построения модели нагрузочного тестирования
16.01.2009 15:02

Автор: Гринкевич Сергей

Оригинальная публикация

Что такое Web-логи?

Любой пользователь, работающий с Интернет приложением, подвергается постоянному наблюдению. За ним следит не только ФСБ (для тех, кто занервничал, читая эти строки, поясняю - это шутка), но и многие участники Глобальной паутины. Это не люди, а электронные компоненты виртуального пространства. И их великое множество. «Стада» совершенно различных серверов, прокси, фаерволов, коммутаторов, маршрутизаторов и т.п. Везде, где вы побывали, остаются «следы» вашего присутствия. Не исключение и Web-сервер на котором работает ваше Web-приложение.

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

Зачем анализировать Web-логи?

Вполне резонный вопрос - собственно, зачем нам это надо?

Целей может быть несколько. В первую очередь, Web-логи могут показать, что именно делал тот или иной посетитель на вашем сайте. Можно посмотреть, откуда пришел пользователь, что он запрашивал, сколько времени потратил на чтение и куда потом делся. Вот такой подробный расклад. В результате может получиться маршрут этого посетителя.

Если изучить маршруты пользователей и выбрать наиболее часто используемые, то можно понять, что именно интересует ваших посетителей. Возможно, это совершенно не то, что вы задумывали, создавая ваш сайт или разрабатывая Интернет приложение.

Что касается нашего случая, то больше всего нас интересует набор операций, которые выполняет пользователь, а так же частота этих действий за некоторый промежуток времени. Далее мы подробнее остановимся на этих характеристиках.

Какие бывают Web-логи?

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

Наиболее распространенным форматом является обычный формат ведения логов - Common Log Format (CLF). Он включает в себя семь полей, которые содержат данные по текущему запросу. Поля и их значения приведены в таблице.

Поле
Значение
Remote host Имя компьютера или IP-адрес запрашивающего клиента
Remote identity Учетная запись пользователя на клиентской машине
Authentication user Имя, указанное пользователем при аутентификации
Time Дата/время запроса
Request Метод запроса, URI запроса и версия протокола
Response code Код HTTP-ответа
Content length Число байтов в ответе

Другим форматом ведения Web-логов является расширенный формат (вполне ожидаемое название ) – Extended Common Log Format (ECLF); и в отличие от простого формата расширенный не имеет жестко закрепленного списка полей. Их конечное количество зависит от разработчиков, создавших Web-сервер.

В качестве примера рассмотрим Web-сервер, выпущенный компанией Майкрософт, - Internet Information Services (IIS). Помимо возможности протоколировать дату и время запроса пользователя, Web-сервер позволяет включить еще 20 параметров. Поля и их значения приведены в таблице.

Поле
Значение
Date Дата запроса
Time Время запроса
Client IP Address IP адрес клиента, отправившего запрос
User Name Имя, указанное пользователем при аутентификации
Service Name Название запрашиваемого сервиса и его номер
Server Name Имя сервера, на котором генерируются лог-файлы
Server IP Address IP сервера, на котором генерируются лог-файлы
Server Port Номер порта, к которому подключился клиент
Method Тип запроса, который использовал клиент (GET, POST …)
URI Stem Тип ресурса, который запросил клиент (HTML, CGI …)
URI Query Параметры, переданные в запросе
Protocol Status Вид протокола (HTTP, FTP …)
Protocol Sabstatus Подвид протокола (специальная функциональность IIS)
Win32 Status Статус операции (специальная функциональность IIS)
Bytes Sent Количество байтов ответа сервера
Bytes Received Количества байтов запроса клиента
Time Taken Время, затраченное на обработку запроса и отправку ответа (в мс)
Protocol Version Версия протокола (HTTP 1.0, 1.1 …)
Host Текст поля заголовка HOST
User Agent Тип брайзера пользователя
Cookie Полученные или отправленные куки
Referrer Адрес сайта, с которого пришел пользователь

Где найти Web-логи?

Web-лог или журнал протоколирования Web-сервера – это текстовый файл, в который записывается информация о каждом запросе каждого пользователя. Паре запрос-ответ соответствует одна запись. Каждое поле записи отделяется от другого знаком табулирования или пробелом, что позволяет легко просматривать и анализировать файл в программе Excel.

Что бы найти путь к лог-файлу необходимо открыть Менеджер Web-сервера (Administrative Tools/Internet Information Services (IIS) Manager), раскрыть дерево ресурсов, находящихся на вашем компьютере, и наведя курсор на поле Web Sites открыть окно Свойства (Properties).

На закладке Web Site находится раздел, посвященный журналу протоколирования. За кнопкой Properties скрывается окно настроек протоколирования. В нижней части закладки General указан путь к лог файлу. По умолчанию, он представляет собой следующую строку: C:\WINDOWS\system32\LogFiles. Ниже приводится название файла, в который ваш Web-сервер пишет данные в настоящий момент. На закладке Advanced можно включить или выключить функцию протоколирования для каждого предусмотренного форматом поля.

Как получить полезную информацию из Web-логов?

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

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

Как было отмечено выше, лог-файл это текстовый файл, который может быть открыт в любом текстовом редакторе. Каждое поле отделено пробелом или знаком табуляции. Для его анализа можно воспользоваться программой Excel. На картинке изображен пример импорта лог-файла в Excel таблицу.

В первую очередь, нас интересует количество пользователей, обратившихся к приложению с запросами за определенный промежуток времени. Эти данные получить очень легко. Достаточно вычислить количество уникальных IP адресов, учтенных системой протоколирования. Например, в лог-файле имеются записи о 134 уникальных IP адресах, с которых были отправлены запросы в течение часа. Это означает, что за контрольный промежуток времени 134 различных пользователей обратились к приложению за информацией.

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

Для вычисления остальных параметров текущей нагрузки удобно пользоваться функцией «Пилотная Таблица» (PivotTable) программы Excel (Date -> PivotTable and PivotChart Report).

Следующей характеристикой нагрузки может служить определение наиболее посещаемых страниц сайта. Эта задача так же не вызывает затруднений. Выделяем всю таблицу, содержащую запросы к Web-серверу, и по ней строим Пилотную таблицу. Затем из Списка Полей Пилотной Таблицы (PivotTable Field List) перетягиваем поле Page в область строк Пилотной Таблицы (Row Area). Затем, то же самое проделываем для поля User, только помещаем его в область данных таблицы (Drop Data Items Here). Для сортировки данных таблицы, выделяем только ячейки колонки Total и нажимаем кнопку сортировки в порядке убывания. Ву-а-ля! Таблица готова.

Стоит отметить лишь одну деталь. Нас интересуют не все элементы, которые могут быть загружены с сервера. Для используемого примера, это htm и asp страницы. Пилотная Таблица позволяет оставить только нужные элементы. Для этого в шапке таблицы в поле Page нужно выбрать выпадающий список и убрать галочку напротив тех элементов, которые нам не важны. Результат показан на рисунке.

Рисунок 2. Выбор элементов таблицы

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

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

Для начала нужно понять, что в работе любого пользователя нас интересуют только успешные запросы, то есть такие, которые имеют код меньше 400. Следовательно, для нашего примера необходимо отбросить те записи таблицы, которые оканчиваются на 401 и 500. Для этого воспользуемся автофильтром. Включив его (Data -> Filter -> AutoFilter) в поле Code выбираем настраиваемый фильтр и задаем критерии отбора. Пример настройки фильтра приведен на картинке.

После применения фильтра в таблице остались только успешные запросы к системе. Теперь из полученных данных нужно выбрать запросы, относящиеся к одному IP или имени пользователя. Возьмем, например, EUROPE\Andre. Результат приведен на картинке.

Рисунок 4. Список успешных запросов

Анализируя полученные данные, можно сказать, что пользователь Andre в течение контрольного времени совершил 8 запросов типа catalog_type со страницы /data/cross_catalog_maintenance.asp (1-е место рейтинга) и 3 запроса типа chassis_id со страницы /data/chassis_module_blurbs.asp (11-е место рейтинга).

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

Для построения такой таблицы необходимо в Row Area и Data Area поместить поле Page, а в Column Area поместить поле User. Результат изображен на картинке.

Рисунок 5. Распределение пользователей по группам

В нижней части таблицы для каждого пользователя посчитан результат активности. К наиболее активным, можно отнести двух пользователей с показателями 231 и 164 запроса к системе. К новичкам так же можно отнести двух пользователей, но уже с минимальным количеством запросов: 2 и 9. Оставшиеся войдут в группу пользователей. Каждая из групп будет иметь свою модель поведения.

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

Для того, что бы увидеть временные паузы между действиями пользователя, воспользуемся Пилотной Таблицей (PivotChart). Имени каждого пользователя необходимо поставить в соответствие запросы, распределенные во времени. В результате, мы получим таблицу, где в ячейке, соответствующей определенному моменту времени, значение будет присутствовать только в том случае, если данным пользователем был отправлен запрос. Пример таблицы приведен на рисунке.

Рисунок 6. Анализ временных пауз

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

Манипулируя списком пользователей и/или списком запрашиваемых страниц в таблице исходных данных, можно провести анализ поведения любой группы пользователей и вычислить усредненные значения интервалов времени между запросами пользователей.

Заключение

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

Обсудить в форуме