ВЧ
Alex Grishutin
Так таймер рандомный вначале каждого скрипта поставить и все
Имеется ввиду в скриптах поставить задержку перед стартом сценария? Такие мысли были, но выглядит как костыль
Size: a a a
2020 August 27
AG
Рабочтий костыль... я так в jmeterдостаточно часто делаю в определенных случаях
ВС
Alex Grishutin
Так таймер рандомный вначале каждого скрипта поставить и все
Есть особый баг. Что таймер именно в начале сценария не работает, пропускается
ΙΤ
Есть особый баг. Что таймер именно в начале сценария не работает, пропускается
поправят это в 3.4.0
ВС
Если в коде самого сценария сделать pause(...), то сработает
AG
Ну тогда фейко запрос на любой статический ресурс и после него паузу)
ВС
поправят это в 3.4.0
Здорово
PB
в целом прогоняется несколько скриптов, и по окончанию на каждый скрипт создается отдельный отчет, чтобы понять, где серввер не справился
как уже сказали выше, можно сделать через ci\cd
можно сделать так что бы после завершения одной джобы - тригерилась другая и всё будет последовательно
можно сделать так что бы после завершения одной джобы - тригерилась другая и всё будет последовательно
AG
Эх... костыли...
ВС
Просто пауза работает. Я ее использую. Чтобы сымитировать Tear Down катушку. Сценарий который выполнится после всех сценариев. В него передаю параметром длину теста, а он сначала ждёт столько времени, а потом работает
ВЧ
как уже сказали выше, можно сделать через ci\cd
можно сделать так что бы после завершения одной джобы - тригерилась другая и всё будет последовательно
можно сделать так что бы после завершения одной джобы - тригерилась другая и всё будет последовательно
Тут в рамках одной джобы создается несколько отчетов и доступа к её редактированию нет
ВЧ
Alex Grishutin
Ну тогда фейко запрос на любой статический ресурс и после него паузу)
А это можно сделать на уровне yml скрипта?
ВС
Yml в Gatling нет же
ВЧ
Yml в Gatling нет же
Скала дергает Yml скрипты со сценариями у нас, запуск с таурусом
DB
а в чем смысл так делать? результаты от запуска к запуску будут непредсказуемы
Последовательный запуск очень удобная штука при отслеживании деградации. Я раньше старался эмулировать реальный профиль нагрузки и на основании результатов тестов с реальным профилем делать сравнения билдов.
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
AG
Последовательный запуск очень удобная штука при отслеживании деградации. Я раньше старался эмулировать реальный профиль нагрузки и на основании результатов тестов с реальным профилем делать сравнения билдов.
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
ТАк вы получается тестируете отдельные элементы системы?
ΙΤ
Последовательный запуск очень удобная штука при отслеживании деградации. Я раньше старался эмулировать реальный профиль нагрузки и на основании результатов тестов с реальным профилем делать сравнения билдов.
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
Здесь есть несколько минусов :
1. Профиль нужно постоянно апдейтить, чтоб он оставался "реальным"
2. Всё равно очень часто оказывается, что профиль не отражает действительность - есть неучтенные транзакции, не покрытые мониторингом, интеграции и т.д.
3. Часто бывает, что при деградации одной части системы это влияет на другие части и становится сложно выявить корневую проблему. К примеру на одном из бекенд инстансов есть несколько эндпоинтов, один из которых начал потреблять больше CPU. Это влияет на время ответа остальных эндпоинтов. В итоге в отчете мы видим замедление по целому ряду транзакций и нужно дополнительно разбираться, какая из них стала причиной замедления остальных
4. При расширении тестового набора нужно увеличивать количество ресурсов на тестовом окружении
В итоге перешел на последовательный запуск в Jmeter. Каждая группа транзакций имеет свою ThreadGroup. На прогон теста для одной группы уходит 10-15 минут. Итоги:
1. Чётко видно деградацию и часть системы в которой она произошла
2. Легко можно расширять тестовое покрытие путем простого добавления новых TreadGroup в конец тест плана
3. Ушла необходимость поддерживать "реальный" профиль без потери результативаности.
Возможно для теста на максперф такой подход не очень подойдет, но при отслеживании деградации дает хорошие результаты
Для монолитов я бы не сказал что подходит
ΙΤ
Да и для микросервисов тоже из разряда пальцем в небо
ΙΤ
Упускается проверка конкуренции за общие ресурсы такие как коннекте к бд
ΙΤ
Или например один сервис улучшился из-за оптимизаций и начал больше через себя пропускать а следующий за ним сервис может нагнуться из-за выросшей нагрузки