ΙΤ
Size: a a a
2021 June 08
AA
Тоже такая мысль, мб лучше авто тесты пилить)
VN
стоит true
нашел различие, которое может повлиять, в первоначальном виде процедура имеет USE table_name GO разделитель, в свойствах двайвера изменил на ; и в клиенте работает именно так, а в jmeter явно указать разделитель не выходит в DB config
нашел различие, которое может повлиять, в первоначальном виде процедура имеет USE table_name GO разделитель, в свойствах двайвера изменил на ; и в клиенте работает именно так, а в jmeter явно указать разделитель не выходит в DB config
NM
Если их нет, то надо уточнить что хочет заказчик, вероятно он хочет узнать как чо, в таком случае можно сделать один прогон, посмотреть время отклика, после чего сделать ступенчатый тест и сказать как минимум, на сколько растет время отклика под какой нагрузкой
NM
у меня такое случается, что проект новый, требований нихрена, но очень надо какую-то точку отсчета, и вот так ее делают. Получается мало говорящая о чем-то хрень, но после следующего деплоя можно сравнить стало лучше или хуже
NM
между временем отклика и тестом надо применить волшебные знания о расчетах сценария и нагрузке, они вроде тоже в шапке были
NM
но лучше дожать заказчика
NM
хотя бы примерами типа 10-20 секунд
JD
Зачем?)
VG
Задача была пропихнуть что-то в jmeter не дожидаясь, пока jmeter сам этого запросит.
Кирилл предложил очень любопытное решение - менять проперти в работающем jmeter через beanshell server / client
Кирилл предложил очень любопытное решение - менять проперти в работающем jmeter через beanshell server / client
VG
Круто, и правда pull.
Из потока, правда, уже нужно будет эти изменения проперти отлавливать постоянными проверками
Но постоянно читать проперти это быстрее, чем постоянно стучаться в заглушку
Надо будет проверить такой метод.
Из потока, правда, уже нужно будет эти изменения проперти отлавливать постоянными проверками
Но постоянно читать проперти это быстрее, чем постоянно стучаться в заглушку
Надо будет проверить такой метод.
2021 June 09
ВС
Если проблема проявляется без нагрузки. То сделайте исследование - куда уходит время. Профилирование. Решение частной проблемы. Вместо написания тестов производительности
JD
Известно, куда уходит время - слишком тяжклые запросы в базу и сложные хранимые процедуры
ВС
Тогда тесты нужны для оценки того, на сколько ускорится UI при ускорении БД. Сделайте хотя бы автотесты. Которые 10-15 раз работают и статистику о себе сохраняют.
Потом поправьте самый медленный запрос и повторите тесты
Требование - должно стать быстрее, чем до ускорения
Потом поправьте самый медленный запрос и повторите тесты
Требование - должно стать быстрее, чем до ускорения
А
Всем, привет. В оф. документации jmeter пишут что можно Constant Throughput Timer менять во время теста. Подскажите кто-нибудь пробовал делать, может есть какой-то оптимальный подход?
KY
оптимальный для какой задачи?) можно то очень много чего
А
Имею ввиду оптимальный подход для изменения таймера во время теста.
А вообще суть в том, что есть "долгие" пользователи на которых выделяется всего 1-2 поток. При этом этим количеством потоков необходимо увеличивать нагрузку. Поэтому пришёл к тому что нужно управлять таймером
А вообще суть в том, что есть "долгие" пользователи на которых выделяется всего 1-2 поток. При этом этим количеством потоков необходимо увеличивать нагрузку. Поэтому пришёл к тому что нужно управлять таймером
А
Тест может быть как со ступенями так и без. Вижу только вариант в каждой тредгруппе считать время и изменять значение таймера.
Может можно как-то это делать централизованно, сделать отдельную тредгруппу для подсчета совсем плохо?) или лучше чем считать в каждой
Может можно как-то это делать централизованно, сделать отдельную тредгруппу для подсчета совсем плохо?) или лучше чем считать в каждой
VG
Недавно Кирилл кидал статью про это: