Анализ Web-логов для построения модели нагрузочного тестирования
#1
Отправлено 21 ноября 2007 - 08:41
Предлагаю вашему вниманию мою статью "Анализ Web-логов для построения модели нагрузочного тестирования", опубликованную на сайте www.DrQuality.ru.
Что такое Web-логи?
Любой пользователь, работающий с Интернет приложением, подвергается постоянному наблюдению. За ним следит не только ФСБ (для тех, кто занервничал, читая эти строки, поясняю - это шутка), но и многие участники Глобальной паутины. Это не люди, а электронные компоненты виртуального пространства. И их великое множество. «Стада» совершенно различных серверов, прокси, фаерволов, коммутаторов, маршрутизаторов и т.п. Везде, где вы побывали, остаются «следы» вашего присутствия. Не исключение и Web-сервер на котором работает ваше Web-приложение.
Следы – это не отпечатки пальцев и не протектор ваших ботинок. Следы - это записи в журналах Web-сервера, первого из элементов типового трехзвенного приложения, включающего собственно сам Web-сервер, а так же Web-приложение и базу данных.
Зачем анализировать Web-логи?
Вполне резонный вопрос - собственно, зачем нам это надо?
Читать статью полностью:
Анализ Web-логов для построения модели нагрузочного тестирования (Часть 1)
Анализ Web-логов для построения модели нагрузочного тестирования (Часть 2)
Буду рад ответить на ваши вопросы.
С уважением,
Сергей.
#2
Отправлено 11 января 2008 - 09:53
Я больше склоняюсь к тому, что анализ логов полезен для траблшутинга когда система уже в продакшине, а не для построения модели нагрузочного тестирования.
#3
Отправлено 14 января 2008 - 09:18
1. анализ логов аналогичных или "близких по духу" создаваемой систем;
2. ваши аналитические способности и предыдущий опыт.
#4
Отправлено 01 апреля 2008 - 06:36
При передаче сервиса/проекта в нагрузочное тестирование, менеджер проекта должен предоставлять развесовку страниц сервиса, деля их на самые популярные и не очень популярные. Т.к. ни кто кроме менеджера проекта не знает о том, как пользователь будет вести себя в том или ином сервисе. Понимаю, что это на уровне фантастики, но все же хотелось, чтобы так было :)
Другая проблема - это то, что таких менеджеров проектов очень мало, которые способны адекватно оценить и прогназировать поведение пользователя в придуманном им сервисе/проекте...
#5
Отправлено 01 апреля 2008 - 10:00
Най мой взгляд данная статья будет очень интересна менеджерам проекта.
На мой взгляд, данная статья будет только полезна бизнес аналитиком.
Но она бесполезна, если у компании есть firewall и выход в Интернет.
_____________________
За что же, не боясь греха,
Кукушка хвалит Петуха?
За то, что хвалит он Кукушку.
#6
Отправлено 01 апреля 2008 - 12:33
Но она бесполезна, если у компании есть firewall и выход в Интернет.
Поясните, что вы имеете в виду ?
#7
Отправлено 01 апреля 2008 - 13:51
Не путайте терминологию. PivotTable = Сводная таблица. Пилотная - сомнительно...
И вообще статья жутко очевидна, просто инструкция по построению сводных таблиц.
Андрей Похилько
#8
Отправлено 01 апреля 2008 - 14:56
И вообще статья жутко очевидна, просто инструкция по построению сводных таблиц.
Какая бы не была статья она всегда будет очевидна для кого-то, это не повод говорить что она очевидна для всех, тем более в таком тоне
#9
Отправлено 01 апреля 2008 - 19:54
IIS и excel
Поясните, что вы имеете в виду ?
При оперделеных насткройках firewall дает IIS только IP адресс firewall так что адресс все время будет один.Но это не самое страшное что все пользователи web приложения могут иметь один аккаунт для логирования. В даной стать очень много если ...
В итоге действительно
И вообще статья жутко очевидна, просто инструкция по построению сводных таблиц.
_____________________
За что же, не боясь греха,
Кукушка хвалит Петуха?
За то, что хвалит он Кукушку.
#10
Отправлено 01 апреля 2008 - 20:52
иНо она бесполезна, если у компании есть firewall и выход в Интернет.
При оперделеных насткройках firewall дает IIS только IP адресс firewall так что адресс все время будет один.Но это не самое страшное что все пользователи web приложения могут иметь один аккаунт для логирования.
1. Ваше "При оперделеных насткройках" (орфография сохранена) - это всего лишь еще одно "если".
2. По всему остальному смотрите комментарий от 14.1.2008, 11:18
#11
Отправлено 02 апреля 2008 - 05:38
И вообще статья жутко очевидна, просто инструкция по построению сводных таблиц.
Совершенно верно!
Это инструкция - как "построить" модель нагрузки.
Если для Вас этот вопрос актуален, то берите и пользуйтесь. Если нет, то не пользуйтесь.
Свобода выбора.
#12
Отправлено 02 апреля 2008 - 08:07
Хотелось бы увидеть хоть одну вашу статью? А то складывается мнение что талант пропадает даром, столько мыслей и замечаний надо уже их систематизировать и написать - других поучитьСогласен статья раскрывает несколько новшевст до сели не известных.
IIS и excel
p.s.: только если надумаете писать смотрите чтобы небыло очевидных вещей, а то мало ли ..
#13
Отправлено 02 апреля 2008 - 08:41
Дать почитать в черновом варианте ?
_____________________
За что же, не боясь греха,
Кукушка хвалит Петуха?
За то, что хвалит он Кукушку.
#14
Отправлено 02 апреля 2008 - 09:13
По теме может и правда что-то напишите?
А про почитать - выкладывайте, почитаем.
Редактор портала www.it4business.ru
#15
Отправлено 02 апреля 2008 - 09:15
А про статьи: вот вам ещё пища для критики: http://pankratov.org...category/qalib/
Редактор портала www.it4business.ru
#16
Отправлено 02 апреля 2008 - 09:17
Книга про то "как надо писать статьи", это тренинг про то как заработать на казино.
По теме может и правда что-то напишите?
А про почитать - выкладывайте, почитаем.
Извините просто какая тема так и пишем !!!
Тема ни о чем и пишем ни о чем ...
_____________________
За что же, не боясь греха,
Кукушка хвалит Петуха?
За то, что хвалит он Кукушку.
#17
Отправлено 02 апреля 2008 - 09:21
Кстати, несмотря на манеру обсуждений, мне лично очень нравится, что sgreeen так рьяно взялся за комментирование: явно человеку не пофиг, что сейчас большая редкость.
А про статьи: вот вам ещё пища для критики: http://pankratov.org...category/qalib/
начал читать
_____________________
За что же, не боясь греха,
Кукушка хвалит Петуха?
За то, что хвалит он Кукушку.
#18
Отправлено 12 апреля 2008 - 16:34
Но она бесполезна, если у компании есть firewall и выход в Интернет.
В логе Web-сервера, кроме ip-адреса, можно найти ещё много уникальной информации, которая позволяет идентифицировать тот или иной запрос и отнести его к тому или иному пользователю. Например идентификатор php-сессии или например уникальный user-id, который может передаваться в качестве параметра в get-запросе. "firewall и выход в Интернет" - это не проблема для таких систем/приложений.
#19
Отправлено 15 апреля 2008 - 09:30
Нагрузочную модель могут характеризовать следующие параметры:
- количество пользователей, одновременно использующих систему в течение контрольного промежутка времени (количество одновременных пользователей);
- наиболее посещаемые страницы сайта;
- типовое поведение пользователей системы;
- паузы в действиях пользователей при переходе от одной страницы к другой (или при использовании различных функций системы).
Анализ Web-логов для построения модели нагрузочного тестирования (Часть 2)
Меня удивило, что в качестве параметра нагрузочной модели взято только число пользователей, одновременно использующих систему. При этом куда-то пропадает количественная, измеримая характеристика качества сервиса для каждого из этих пользователей. Например, среднее время отклика. Или пропускная способность системы. Согласитесь, что система может дать возможность отправить к ней запрос и ста пользователям, и тысяче, но насколько адекватным будет качество обслуживания этих запросов? Мне кажется, это должно быть явно указано в модели, иначе выходит как в мультфильме про скорняка и шапки для барина - хошь, одну шапку сошью а хошь - десять, все из одной шкурки.
То же замечание по наиболее посещаемым страницам сайта. Эти данные нужны и интересны, и, как вариант, будут определять те сценарии, по которым можно проводить нагрузочное тестирование при прогнозировании возможностей системы под стрессовой нагрузкой, но если говорить о количественной модели нагрузки, то тоже нужна характеристика качества сервиса этих страниц, а число одновременных пользователей, обращающихся к этим страницам, само по себе такой характеристикой не является.
А вот паузы в действиях пользователей для модели нужны, но эта линия статьи как-то не до конца развита в обсуждаемой статье при описании модели нагрузки.
Хотелось бы увидеть пример того, зачем они нужны. Как вариант, когда на основе анализа реальной нагрузки планируется количество виртуальных пользователей.
Скажем, в книге Менаске Д., Алмейда В. Производительность Web-служб. Анализ, оценка и планирование приводится такой расчет:
То есть можно было бы явно показать, как из требования к системе на N конкурирующих пользователей и из данных о паузах, полученных из анализа логов сервера, можно рассчитать количество виртуальных пользователей, которое уже можно использовать при тестировании.Задачей тестирования является измерение возможностей и производительности серверов приложений. Команда специалистов также желает убедиться в том, что время отклика приложения будет находиться в заданных границах в условиях реальной нагрузки. Тестируемая система - это web система по обслуживанию кредитов, рассчитанная на 100000 пользователей, которые смогут в ней выполнять основные операции с банковскими счетами: просматривать состояние счета, изменять персональную информацию, подавать заявки на получение кредита. Нагрузка системы указана числом конкурирующих пользователей. Бизнес-аналитик оценивает среднее количество конкурирующих пользователей как 1% от общего числа пользователей.
При анализе нагрузки системный аналитик указыват, что наиболее часто вызываемый и потребляемый значительную долю ресурсов пользовательский запрос - это просмотр состояния банковского счета. Автоматическая эталонная программа создает виртуальных пользователей, которые генерируют тестовую нагрузку. Установлен режим, в котором виртуальный пользователь получает ответ, он сразу же посылает новый запрос (время обдумывания Z для него равно 0).
Для определения тестовой нагрузки следует указать число конкурирующих виртуальных пользователей.
Пусть R - среднее время отклика приложений,
Xo - пропускная способность сервера
Nr - количество одновременных реальных пользователей
Nv - количество одновременных виртуальных пользователей
Учитывая, что пропускная способность и время отклика должны быть одинаковы при тестировании в реальных условиях, можно записать:
Xo = Nr / (R + Z)
Xo = Nv / (R + 0)
Отсюда: Nv / Nr = R / (R + Z)
Предположим, что нам надо достичь значения среднего времени отклика R = 2 c и Z = 20 c для реальных пользователей
Тогда: Nv = Nr * 2 / (2 + 20) = 1000 * 1/11 = 90.9 ~ 91
Таким образом, при тестировании необходимо использовать до 91 виртуальных пользователей.
В общем, я бы подумала в направлении уточнения модели и перспектив ее использования при прогнозировании стрессовой нагрузки.
#20
Отправлено 16 апреля 2008 - 08:19
Меня удивило, что в качестве параметра нагрузочной модели взято только число пользователей, одновременно использующих систему. При этом куда-то пропадает количественная, измеримая характеристика качества сервиса для каждого из этих пользователей. Например, среднее время отклика. Или пропускная способность системы. Согласитесь, что система может дать возможность отправить к ней запрос и ста пользователям, и тысяче, но насколько адекватным будет качество обслуживания этих запросов? Мне кажется, это должно быть явно указано в модели, иначе выходит как в мультфильме про скорняка и шапки для барина - хошь, одну шапку сошью а хошь - десять, все из одной шкурки.
Привет, Олешка!
Что-то давненько тебя не было.
Твои замечания вполне справедливы. Постараюсь внести ясность.
В первую очередь, я разделяю понятия "модель нагрузки" и критерии успешности тестирования. В первый термин я включаю именно модель того, в каких условиях система будет эксплуатироваться. В второй - пи каких условиях результаты испытаний следует считать успешными (либо не успешными).
Приведу пример.
Есть on-line почтовик с web интерфейсом. Необходимо провести нагрузочное тестирование системы.
1. Определяем роли пользователей.
2. Выделяем пользовательские сценарии и определяем "вес" каждой операции.
3. Определяем объем и структуру тестовой базы данных на сегодняшний день и на полгода - год вперед.
Это и есть моделирование типовой работы с нашим сервисом. В результате анализа модели выделяем операции, которые должны быть реализованы в виде тестовых скриптов, а так же их "вес" в общем сценарии. Вес может быть выражен в % или долях. Например, в ежедневной нагрузке:
- 10% пользователей проходят регистрацию,
- 80% удаляют спам,
- 30% пользователей удаляет сообщения,
- 60% вводят новые сообщения,
- 55% отправляют сообщения и т.д.
4. Для определения успешности испытаний запрашиваем бизнес (либо формулируем самостоятельно) критерии успешности. А именно - какова должна быть скорость реакции системы при определенном количестве пользователей.
Продолжая пример можно написать так, что при 100.000 одновременных пользователях скорость реакции системы не должна превышать 7 секунд. Но это не есть модель нагрузки (в моем представлении). Модель нагрузки - это то, что программируется (реализуется) в тестовых скриптах - действия пользователей и "вес" этих действий в общем объеме операций.
Фактически критерии успешности могут меняться в зависимости от требований бизнеса (например, конкуренты сделали быстрее чем у нас и теперь мы должны обойти конкурентов), а модель нагрузки постоянна. Она обусловлена логикой работы системы и пользовательскими предпочтениями. Если у нас только 10% пользователей присваивают теги письмам для фильтрации по тегам, то и через полгода - год это примерное процентное соотношение сохранится, если данная функциональность не будет изменена на более удобную или не будут проведены дополнительные "продвигающие" мероприятия. Но без дополнительных воздействий на манеру работы пользователей модель нагрузки практически не меняется.
Другой пример модели нагрузки. В крупной компании (100.000 пользователей) все приходят на работу в 9 часов и запрашивают почту с сервера. С 9 до 9:30 приходится пик нагрузки на почтовый сервер. Так вот, модель нагрузки будет включать в себя операцию по коннекту почтового клиента к почтовому серверу, а критерий успешности - 100.000 одновременных пользователей, максимальное время отклика не более 10 секунд. Для другой компании количество пользователей и время отклика системы может иметь другие значения, но модель нагрузки не изменяется, если другая компания имеет такой же режим работы.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных