Телеграмм чат группы qa

Size: a a a

QA — Load & Performance

1334 membersпожаловаться на группу

2019 October 24

ВС

Вячеслав Смирнов in QA — Load & Performance

Нагрузка бывает разная очень. Думаю, что стоит посчитать длительность работы => стоимость

источник

09:45пожаловаться #1

ВС

Вячеслав Смирнов in QA — Load & Performance

Предложить сразу мониторинг производительности, оценку его настройки. Какие показатели мы будем мониторить. И почему их.

Запросы в сек. Сценарии в сек.

Узнать сколько сценариев в день/месяц бизнес ждёт от проекта. Может он ждет, что будет 10 000 покупок в месяц.

источник

09:47пожаловаться #2

ВС

Вячеслав Смирнов in QA — Load & Performance

И дальше предложить самый простой тест на проверку того, что такое количество достижимо

источник

09:48пожаловаться #3

redden in QA — Load & Performance

+ определить пределы оборудования

источник

09:49пожаловаться #4

ВС

Вячеслав Смирнов in QA — Load & Performance

И если получится, что все хорошо. То ограничиться мониторингом.

А если проект нагрузку не держит, то предложить доп проект. С примерной стоимостью работ

источник

09:49пожаловаться #5

Maksim Nartov in QA — Load & Performance

Самый простой вариант - спросить у бизнеса, что будет, если ресурс будет недоступен целый день, например

источник

09:49пожаловаться #6

Maksim Nartov in QA — Load & Performance

Если они скажут, что это ужас, то крути дальше

источник

09:50пожаловаться #7

Maksim Nartov in QA — Load & Performance

При условии, что бизнес вообще понимает, зачем этот ресурс им нужен

источник

09:50пожаловаться #8

ВС

Вячеслав Смирнов in QA — Load & Performance

Ещё есть такой момент, если оценить работу дорого. То заказчик выставит к тестированию требования, которые невозможно выполнить.
А именно. Так называемые "реальные пользователи", "настоящие" сценарии, ...
С "прогнозированием" нагрузки на продуктиве по результатам нагрузки на тестовом стенде.

Это почти сразу - гиблое дело

источник

09:55пожаловаться #9

ВС

Вячеслав Смирнов in QA — Load & Performance

Проще начать с простого проекта, с простой задачей, понятной реализацией и сроками. Получить первый успешный результат. А уже потом продолжить сотрудничество.

источник

09:57пожаловаться #10

Aleksandr in QA — Load & Performance

Artem Rozhkov

Вопрос можно поставить так. Какой проект стоит нагружать , а какой нет?

Нагружать надо любой проект, от которого требуется многопользовательская работа или есть требования к производительности.
Можно не проводить НТ, и просто страховать риски, например выкатывая круглый штраф подрядчику по разработке за каждый простой и недоступность. А перед этим зафиксировать SLA.
Но это сложно, ибо если разработка ваша собственная, то что?

источник

12:20пожаловаться #11

Dmitry in QA — Load & Performance

Но при этом наличие НТ не гарантирует вам отсутствие даунтайма🤪

источник

12:23пожаловаться #12

МК

Максим Какбыпограммизд in QA — Load & Performance

Aleksandr

штрафовать разработчика 😁

источник

12:26пожаловаться #13

Aleksandr in QA — Load & Performance

Максим Какбыпограммизд

штрафовать разработчика 😁

Во-во, звучит как - нереально :))
Ну либо придумать механизм мониторинга и отката, и взбодрить эксплуатацию откатами патчей и сред на проде при ухудшении производительности.
Я знаю людей, кто живёт по такой схеме, но это ой-ой как непросто.

источник

12:34пожаловаться #14

ВС

Вячеслав Смирнов in QA — Load & Performance

Ιωάννης Τσεκούρι

but i recommend sbt
https://github.com/gatling/gatling-sbt-plugin-demo

GitHub

gatling/gatling-sbt-plugin-demo

An sample project to showcase to showcase Gatling's SBT Plugin - gatling/gatling-sbt-plugin-demo

Satanic build tool

источник

14:32пожаловаться #15

ΙΤ

Ιωάννης Τσεκούρι in QA — Load & Performance

Satanic build tool

14:36пожаловаться #16

Alex Grishutin in QA — Load & Performance

@smirnovqa
Привет, а напомни пожалуйста про какой хидер ты говорил, через который можно эмулировать запрос из разных локаций

источник

16:37пожаловаться #17

ВС

Вячеслав Смирнов in QA — Load & Performance

Вячеслав Смирнов

Другой вариант - самостоятельно отправлять из нагрузочного скрипта запросы в заголовком X-Forward-For и разными ip-адресами. Для JMeter через Header Manager можно сделать. А ip-адреса брать из csv файла.

На балансировщике настроить проброс заголовка forwardfor дальше, если он есть в запросе клиента. Так для haproxy опция называется


option forwardfor

Для nginx
Можно разобраться по документации
https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

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

В Python и Symfony
https://symfony.com/doc/2.2/components/http_foundation/trusting_proxies.html

В Scala/Java и Play

https://www.playframework.com/documentation/2.7.x/HTTPServer

play.http.forwarded.trustedProxies=["192.168.0.0/24", "::1", "127.0.0.1"]

Nginx

Using the Forwarded header | NGINX

NGINX configuration and caveats for deploying the Forwarded header.

Вот такой заголовок

Forward-for
X-Forward-For

источник

16:43пожаловаться #18

Alex Grishutin in QA — Load & Performance

Спасибо

источник

16:47пожаловаться #19

Дмитрий in QA — Load & Performance

Кто сталкивался с тем, что подгружаемые ресурсы запроса грузятся по сто раз в цикле в Джемете 5.1? Вроде кто то писал об этом, если не ошибаюсь

источник

17:49пожаловаться #20