Набор метрик для тестирования веб сервисов

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

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

Сейчас меня наверное будут ругать и банить за ответ на некорректный вопрос (и поощрение таким образом дальнейших некорректных вопросов), ну да ладно.
Вообще-то это зависит от целей тестирования и отчасти от использованного сервера приложений.
В приведённой постановке могу предложить замерить времена отклика методов сервиса, количество потоков в сервере приложений и процент попадания в кеш http запросов. Отклонение процента попадания в кеш от нуля свидетельствует о недостаточности объёма тестовых данных.
Для результатов корректного эксперимента справедливо отношение:
N_ср = SUM_i(T_i_ср * I_i)
N_ср - среднее количество потоков;
T_i_ср - среднее время отклика i-го метода сервиса;
I_i - интенсивность вызовов i-го метода сервиса.
Осреднение проводится по времени эксперимента.
Нарушение этой зависимости может свидетельствовать о неправильной расстановке счётчиков времён отклика и других проблемах.

Для результатов корректного эксперимента справедливо отношение:
N_ср =  SUM_i(T_i_ср * I_i)
N_ср - среднее количество потоков;
T_i_ср - среднее время отклика i-го метода сервиса;
I_i - интенсивность вызовов i-го метода сервиса.

А нигде не вкралась ошибка? Как-то формула не проходит проверку на логику:
Средняя величина (N_ср) должна быть по логике чем-то вроде [Всё_кол-во_потоков/Всё_время], а не никак не суммой произведений среднего времени отклика () и интенсивности (если мы правильно пониманием, что Интенсивность вызовов это количество делить на время).

А нигде не вкралась ошибка?

Я думаю не вкралась. Формула по размерности сходится, потому что среднее величины имеет ту же размерность что и сама величина, т.е. [N_ср] ~ шт.

По размерности я проверил в первую очередь ;)
Я не к размерности придираюсь, а к логике. Откуда эта формула, подскажите источник?

Откуда эта формула, подскажите источник?

Если здравый смысл и мой персональный опыт не устраивает, то я действительно встречал её без суммы (для одной операции) где-то под фамилией какого-то, видимо, американца.
А в чём логическое противоречие формулы, на Ваш взгляд?
Для того чтобы обслужить операцию которая выполняется 5 с и имеет интенсивность 1 c^-1 нужно 5 потоков. Для двух таких операций - 10 потоков.

ошибка ИМХО таки в формуле : SUM_i(T_i_ср * I_i) - это сумма средних количеств методов по всем методам (что само по себе не есть среднее).
Для среднего нужно его разделить на количество рассматриваемых методов (либо еще как-то учесть, что у вас *сумма* по операциям, которую нужно усреднять)

ошибка ИМХО таки в формуле : SUM_i(T_i_ср * I_i) - это сумма средних количеств методов по всем методам (что само по себе не есть среднее).

SUM_i(T_i_ср * I_i) - это сумма средних количеств [одновременных выполнений] методов по всем методам. Сумма мат. ожиданий случайных величин - тоже мат. ожидание. Кстати, если вместо среднего времени отклика взять медиану, то ещё интереснее получится (медиана не аддитивная величина в отличие от среднего).

Для среднего нужно его разделить на количество рассматриваемых методов (либо еще как-то учесть, что у вас *сумма* по операциям, которую нужно усреднять)

Не надо делить ни на время, ни на количество операций, ни на узлы кластера. Делить надо было на количество точек в ряду значений попавших в требуемый временной интервал.
N_ср=SUM_j(N_j)/n
T_i_ср=SUM_j(T_i_j)/n
P.S. Ну или, если Вы замерили количество потоков как непрерывную величину, то интегрируйте и действительно, делите на длину временного интервала T. :)

Сообщение отредактировал a66at: 23 марта 2007 - 12:07

Сумма мат. ожиданий случайных величин - тоже мат. ожидание.

Я, конечно, очень сильно извиняюсь, но матожиданием чего по-Вашему будет сумма матожиданий ???

Рассмотрим частный случай для 2 выборок {x}i,n и {y}j,n :
M(x) = (1/n) * SUM i,n (x_i)
M(y) = (1/n) * SUM j,n (y_j)
Если взять среднее суммы их матожиданий, то легко видеть что это :
(M(x) + M(y)) / 2 = ((1/n) * (SUM i,n (x_i) + (1/n) * SUM i,n (x_i)) / 2 =
(1/2n) * (SUM k,2n (z_k)) = M(z)
где z- объединение выборок.
z_k = x_k, if k <=n
z_k = y_k-n, if k > n
легко заметить, что это выполняется и для бОльшего количества выборок ;)
... а ИМО если брать сумму матожиданий ... гм ... то это будет просто : сумма матожиданий

Кстати, если вместо среднего времени отклика взять медиану, то ещё интереснее получится

вово! Берите лучше медиану. Заодно не надо будет аномальные значения отсеивать.

PS: Прошу прощения у автора топика, что не могу предложить ни своих критериев анализа, ни метрик

матожиданием чего по-Вашему будет сумма матожиданий ?

Навскидку из гугла. http://dfe3300.karel...ory/unit-6.html
"Математическое ожидание суммы случайных величин всегда равно сумме их математических ожиданий: М(х+y) = Мх + Мy"
Для медианы и вообще персентайлов это неверно.

Формула эта верная, уверяю Вас. Не надо даже сервер приложений ставить, чтобы проверить.
Если в неё вместо T_ср подставить критерии по временам отклика, то N будет минимальное количество vuser-ов необходимое для моделирования профиля нагрузки по синхронным операциям.

Коллеги!

Мат*рное ожидание - это конечно круто!
Но все значительно проще.

Шаг 1.
Для проведения нагрузочного тестирования нужно разработать модель системы. В рамках модели определяется - что есть номальная нагрузка, что есть пиковая нагрузка, какие критерии успешности тестирования.

Шаг 2.
Дальше проводится воспроизведение модели в тестовых скриптах.

Шаг 3.
Проводится тестирование, нагружается система, измеряется время отклика системы при данной модели нагрузки. Если время отклика укладывается в критерии успешности (время отклика системы на запрос) - система работает удовлетворительно. Если не укладывается - в системе есть узкое место, которое не дает достигнуть критерия успешности.

Шаг 4.
Анализируем показатели системных счетчиков для выявления узкого места. Делаем предположение, что является узким местом и отправляем результаты разработчикам для устранения узкого места.

Шаг 5.
Повторяем шаг 3. Если укладываемся в критерии успешности - конец. Если нет, то повторяем шаг 4. И так до тех пор, пока не будет достигнут критерий успешности.


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

Мат*рное ожидание - это конечно круто!
Но все значительно проще.

Да, всё действительно очень просто. :) Всю методологию тестирования производительности действительно можно уместить на одной страничке. Вместе с ограничениями метода и ссылками на сходные методы - на трёх. Вместе с красочными иллюстрациями применения - на пяти. Именно поэтому про нагрузочное тестрование пишут статьи, а не монографии. ;)
Автор топика не спрашивал про методологию. Ей владеют очень многие. И, как показывает практика, отличное владение ей не гарантирует от того чтобы протестировать вместо самой системы какой-нибудь очередной патентованный кеширующий контур. Именно поэтому так важно смотреть в мониторинге, действительно ли поведение системы адекватно модели нагружения. Я как мог постарался поставить интересующихся этим вопросом на правильный путь.

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

Хоть и не в тему, но не хочется проходить мимо. Мне кажется, что описанный артефакт корректнее назвать моделью нагружения. Модель системы - это совсем другое.

А в чём логическое противоречие формулы, на Ваш взгляд?

Кроме того что она не удовлетворяет определению *среднего* ничего.

Среднюю скорость движения по ней можно вычислить, к примеру?

А в чём логическое противоречие формулы, на Ваш взгляд?

Кроме того что она не удовлетворяет определению *среднего* ничего.

Среднюю скорость движения по ней можно вычислить, к примеру?

Теперь мысль понял. Эта формула не является определением среднего. Как для неё считаются средние я уже написал. Она просто выражает функциональную связь, которая должна наблюдаться между экспериментально полученными значениями.

Тогда, наверное, я не понял её предназначение: можете на словах перефразировать, если не сложно?

Тогда, наверное, я не понял её предназначение: можете на словах перефразировать, если не сложно?

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

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

Хоть и не в тему, но не хочется проходить мимо. Мне кажется, что описанный артефакт корректнее назвать моделью нагружения. Модель системы - это совсем другое.

Коль пошла такая пьянка...

То "модель нагружения" - это не по-русски. Того и гляди, в последующих топиках, как в испорченом телефоне, определение трансформируется в модель погружения.


Предлагаю назвать "модель нагрузки".

Её предназначение - валидировать результаты.

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

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

В самую точку!

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

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

1. Самый простой - отключаете кеш.
2. Если откючить кеш невозможно, обнуляете его и используете только уникальные запросы.

Нужно учитывать, что все факторы невозможно контролировать. К примеру, механизм оптимизации окна в протоколе передачи данных TCP/IP. Он уже заложен в реализацию и обойти его не получится. Значит, делаем на это скидку, закладываем погрешность и стараемся свести его влияние к минимуму за счет проведения нескольких итераций тестирования в идентичных условиях.

Спасибо всем за советы