Size: a a a

QA — Load & Performance

2021 July 06

KD

Keeper Den in QA — Load & Performance
Jmeter
источник

VG

Viktor Ganeles in QA — Load & Performance
Если запрос один - не вижу смысла
источник

KD

Keeper Den in QA — Load & Performance
Спасибо
источник

VG

Viktor Ganeles in QA — Load & Performance
Транзакция - это набор операций, объединённых в одну пачку.

Считается успешной если все составляющие её операции выполнились успешно.

Длительность транзакции определяется суммарной длительностью составляющих её действий
источник

VG

Viktor Ganeles in QA — Load & Performance
В данном случае действие одно, значит нет разницы между «действие в транзакции» и «действие атомарно»
источник

KD

Keeper Den in QA — Load & Performance
ну вот  я, следуя этой же логике, и пишу их вне контроллера. Сомневался в идеологической правоте)
источник

NM

NoEndOutcry💡🔋🚓 Mikst... in QA — Load & Performance
Ну и действия обернутые в транзакшн-контроллер удобно отслеживать одной транзакцией по времени что в жеметре, что в графане, те. получаешь четкую информацию о выполнении всего сценария внутри контроллера
источник

KD

Keeper Den in QA — Load & Performance
Спасибо @Mikstyraspb
источник

NM

NoEndOutcry💡🔋🚓 Mikst... in QA — Load & Performance
🤪
источник

VG

Viktor Ganeles in QA — Load & Performance
Ничто не мешает отслеживать действия И по-одному И в транзакции :)

Но если сумма действий не важна, а важно лишь каждое по-отдельности - транзакция становится и вовсе бесполезной :)
источник

NM

NoEndOutcry💡🔋🚓 Mikst... in QA — Load & Performance
Ага еще и смущает заказчика
источник

NM

NoEndOutcry💡🔋🚓 Mikst... in QA — Load & Performance
"а чо это у вас за действие в отчете?"(с)
источник

А

Апельсин in QA — Load & Performance
Так легко ответить на чем написано, посмотри в монитор разработчика, в чем работает и как выглядит. Андроид студио значит джава Котлин плюс андроид студио.
источник

KY

Kirill Yurkov in QA — Load & Performance
транзакции часто являются лишним шагом интерпретации в результатах. сначала видишь название "покупка", потом скроллишь чтобы понять, что в эту транзакцию входит, если такая информация есть. потом видишь "покупка" выполняется долго, а почему? а не ясно, какая из внутрилежащих операций работает плохо.
источник

KY

Kirill Yurkov in QA — Load & Performance
"информация вас шокирует, но это запрос к вашей системе...."
источник

VG

Viktor Ganeles in QA — Load & Performance
С другой стороны,  с транзакцией зачастую оценивать результаты проще:
Я заворачиваю в транзакцию каждое пользовательское действие + бизнес-кейсы целиком.

И если я вижу, что весь кейс «покупка» выполнился быстро - смотреть на времена отклика составляющих его 10-50 запросов уже не нужно.

Кейсов у меня в сценарии 15, а запросов - даже не знаю.. больше тысячи.
источник

VG

Viktor Ganeles in QA — Load & Performance
Если же я вижу, что «покупка» целиком отработала медленно - сперва я смотрю, какое составляющее её действие отработало медленно, и только потом смотрю на запросы, из которых состоит это действие.

Приходится посмотреть на всего 1 родительскую транзакцию (бизнес-кейс покупка), 5 её дочерних транзакций (действия пользователя при покупке) и 10 составляющих её запросов

И на каждом этапе обычно только один элемент сильно выделяется по длительности
источник

VG

Viktor Ganeles in QA — Load & Performance
(Последние сообщения скорее для вас, чем для Кирилла :)))) )
источник

KY

Kirill Yurkov in QA — Load & Performance
с тобой все ясно) у тебя всегда кейс обратный моему и куча шумной статики. я же про большинство проектов где нет тысячи запросов. надо делать атомарно чтобы не делать повторный тест по выявлению проблем в рамках транзакции
источник

AR

Artem Rozhkov in QA — Load & Performance
А по-моему , можно же сделать, чтобы всю транзакцию показывал и каждый запрос в частности
источник