AR
Так...
Size: a a a
2020 March 21
AR
Надо спать идти.
W
привет. а можешь развернуть мысль? я часто использую weighted switch и подобные элементы для ветвлений в сценарном тесст плане. не первый раз слышу мысль, что это антипаттерн.
Ну и как @smirnovqa говорил у if и switch проблемы с контролем интенсивности. То есть если тебе строго какое-то количество запросов определённого типа сделать, то с if этого трудно добиться. С if будет когда 10 тпс, а когда и 20 тпс. Ну по крайней мере у меня такое было.
W
И вообще if оператор в циклах для перформанса очень плохо, потому что он векторизацию ломает)))
2020 March 22
KY
Первый недостаток сценариев с условиями - нельзя узнать заранее, сколько запросов будет в сценарии, а значит, как долго они будут выполняться. Для JMeter/LoadRunner, с их закрытой моделью нагрузки, это означает, что нельзя выставить шаг нагрузки точно. И его выставляют по большей границе - для 10-ти запросов. И в результате тест требует 10 000 потоков. Люди запускают и говорят, что инструмент тормозит. Или вообще ставят настройки шага и потоков неверно.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
Второе. В отчёте, нет информации какие же сценарии в результате выполнились.
Третье. Сделать IF-ы не так-то просто. Вот коллеги выше ломают копья. Тест получается часто некорректным, со скрытыми ошибками.
интересный взгляд, даже не могу представить зачем заранее знать точно сколько запросов будет в сценарии и сколько они будут выполняться, если можно просто перезаложить количество тредов, взяв за основу самый долгий из предполагаемых сценариев?
в сообщении не понятным остался момент про переход от 10 запросов к 10000 потоков, если не сложно можно пример такого антипаттерна?
в сообщении не понятным остался момент про переход от 10 запросов к 10000 потоков, если не сложно можно пример такого антипаттерна?
KY
Ну и как @smirnovqa говорил у if и switch проблемы с контролем интенсивности. То есть если тебе строго какое-то количество запросов определённого типа сделать, то с if этого трудно добиться. С if будет когда 10 тпс, а когда и 20 тпс. Ну по крайней мере у меня такое было.
все зависит от задачи, достичь в тестах имитации "реальных" юзеров - задача чаще всего невозможная или заоблачно дорогая.
чем будет кардинально отличается тест с точки зрения анализа результатов, который содержит в себе if, который выдает немного ломанную нагрузку и допустим 2 катушки, которые выдают ровную каждую ступень?
по факту мы увидим количество запросов при которых системе стало плохо, ни в первом, ни во втором случае - не факт, что это количество верное, оно может быть значением между шагами, например.
чем будет кардинально отличается тест с точки зрения анализа результатов, который содержит в себе if, который выдает немного ломанную нагрузку и допустим 2 катушки, которые выдают ровную каждую ступень?
по факту мы увидим количество запросов при которых системе стало плохо, ни в первом, ни во втором случае - не факт, что это количество верное, оно может быть значением между шагами, например.
ВС
интересный взгляд, даже не могу представить зачем заранее знать точно сколько запросов будет в сценарии и сколько они будут выполняться, если можно просто перезаложить количество тредов, взяв за основу самый долгий из предполагаемых сценариев?
в сообщении не понятным остался момент про переход от 10 запросов к 10000 потоков, если не сложно можно пример такого антипаттерна?
в сообщении не понятным остался момент про переход от 10 запросов к 10000 потоков, если не сложно можно пример такого антипаттерна?
Вот об этом и говорю.
Есть сценарий, с условными ветками. Он может выполняться за 3 запроса и за 10. И пусть за 3 запроса он выполняется 30 секунд, а за 10 - 90 сек.
Тут пока всё просто.
Рассчитываем профиль нагрузки:
100 сценариев в секунду.
Знаем, что каждый из них должен выполняться 90 секунд максимум. С запасом - 100 сек.
И вот нам надо для старта 100 штук в сек, пул из 100 * 100 = 10 000 потоков.
Хотя могли бы обойтись двумя катушками.
Для сценария в 30 секунд использовать свой пул.
Для сценария в 90 секунд использовать свой пул.
И получилось бы не 10 000 потоков, а меньше.
Для конкретики. Пример с двумя катушками.
Сценарий 1 (3 запроса) - 30 сек, нужно 50 стартов в сек. При шаге 40 сек, нужно 50 * 40 = 2 000 потоков.
Сценарий 2 (10 запросов) - 90 сек, нужно 50 стартов в сек. При шаге 100 сек, нужно 50 * 100 = 5 000 потоков.
И того 7 000 < 10 000.
Есть сценарий, с условными ветками. Он может выполняться за 3 запроса и за 10. И пусть за 3 запроса он выполняется 30 секунд, а за 10 - 90 сек.
Тут пока всё просто.
Рассчитываем профиль нагрузки:
100 сценариев в секунду.
Знаем, что каждый из них должен выполняться 90 секунд максимум. С запасом - 100 сек.
И вот нам надо для старта 100 штук в сек, пул из 100 * 100 = 10 000 потоков.
Хотя могли бы обойтись двумя катушками.
Для сценария в 30 секунд использовать свой пул.
Для сценария в 90 секунд использовать свой пул.
И получилось бы не 10 000 потоков, а меньше.
Для конкретики. Пример с двумя катушками.
Сценарий 1 (3 запроса) - 30 сек, нужно 50 стартов в сек. При шаге 40 сек, нужно 50 * 40 = 2 000 потоков.
Сценарий 2 (10 запросов) - 90 сек, нужно 50 стартов в сек. При шаге 100 сек, нужно 50 * 100 = 5 000 потоков.
И того 7 000 < 10 000.
W
все зависит от задачи, достичь в тестах имитации "реальных" юзеров - задача чаще всего невозможная или заоблачно дорогая.
чем будет кардинально отличается тест с точки зрения анализа результатов, который содержит в себе if, который выдает немного ломанную нагрузку и допустим 2 катушки, которые выдают ровную каждую ступень?
по факту мы увидим количество запросов при которых системе стало плохо, ни в первом, ни во втором случае - не факт, что это количество верное, оно может быть значением между шагами, например.
чем будет кардинально отличается тест с точки зрения анализа результатов, который содержит в себе if, который выдает немного ломанную нагрузку и допустим 2 катушки, которые выдают ровную каждую ступень?
по факту мы увидим количество запросов при которых системе стало плохо, ни в первом, ни во втором случае - не факт, что это количество верное, оно может быть значением между шагами, например.
Ну тогда и профили нагрузки не нужны)))
W
Зачем нам какие-то пропорции соблюдать между сценариями/запросами
W
Можно равномерно всеми возможными запросами закидывать
W
Ну вообще всё от целей зависит как тут много раз уже говорилось
W
Где-то просто считают что нужно ровно в профиль попадать
KY
Можно равномерно всеми возможными запросами закидывать
не понял аналогию, почему такой вывод?
W
Где-то допустимы отклонения в 5-10 %
KY
Зачем нам какие-то пропорции соблюдать между сценариями/запросами
а на что влияет эта пропорция. допустим я подаю 10 запросов в секунду типа А из 10 катушек или из одной, есть разница?
KY
Вот об этом и говорю.
Есть сценарий, с условными ветками. Он может выполняться за 3 запроса и за 10. И пусть за 3 запроса он выполняется 30 секунд, а за 10 - 90 сек.
Тут пока всё просто.
Рассчитываем профиль нагрузки:
100 сценариев в секунду.
Знаем, что каждый из них должен выполняться 90 секунд максимум. С запасом - 100 сек.
И вот нам надо для старта 100 штук в сек, пул из 100 * 100 = 10 000 потоков.
Хотя могли бы обойтись двумя катушками.
Для сценария в 30 секунд использовать свой пул.
Для сценария в 90 секунд использовать свой пул.
И получилось бы не 10 000 потоков, а меньше.
Для конкретики. Пример с двумя катушками.
Сценарий 1 (3 запроса) - 30 сек, нужно 50 стартов в сек. При шаге 40 сек, нужно 50 * 40 = 2 000 потоков.
Сценарий 2 (10 запросов) - 90 сек, нужно 50 стартов в сек. При шаге 100 сек, нужно 50 * 100 = 5 000 потоков.
И того 7 000 < 10 000.
Есть сценарий, с условными ветками. Он может выполняться за 3 запроса и за 10. И пусть за 3 запроса он выполняется 30 секунд, а за 10 - 90 сек.
Тут пока всё просто.
Рассчитываем профиль нагрузки:
100 сценариев в секунду.
Знаем, что каждый из них должен выполняться 90 секунд максимум. С запасом - 100 сек.
И вот нам надо для старта 100 штук в сек, пул из 100 * 100 = 10 000 потоков.
Хотя могли бы обойтись двумя катушками.
Для сценария в 30 секунд использовать свой пул.
Для сценария в 90 секунд использовать свой пул.
И получилось бы не 10 000 потоков, а меньше.
Для конкретики. Пример с двумя катушками.
Сценарий 1 (3 запроса) - 30 сек, нужно 50 стартов в сек. При шаге 40 сек, нужно 50 * 40 = 2 000 потоков.
Сценарий 2 (10 запросов) - 90 сек, нужно 50 стартов в сек. При шаге 100 сек, нужно 50 * 100 = 5 000 потоков.
И того 7 000 < 10 000.
понял, спасибо.
W
а на что влияет эта пропорция. допустим я подаю 10 запросов в секунду типа А из 10 катушек или из одной, есть разница?
Со стороны инструмента НТ и управления потоками есть
W
А так нет
KY
Со стороны инструмента НТ и управления потоками есть
но поток в инструменте!= проток в нагружаемой системе
таким образом получается, что ветвления не так и плохи, если не стоит проблема с ресурсами
таким образом получается, что ветвления не так и плохи, если не стоит проблема с ресурсами
KY
по поводу того, зачем заранее знать сколько запросов будет в сценарии, кроме того чтобы определить количество тредов - я пока не могу представить :)