Size: a a a

QA — Load & Performance

2019 November 05

AV

Andrey Vasiliev in QA — Load & Performance
довольно любопытное использование грэйлога 🙂 есть примеры в открытом доступе? может ввиде контейнеров?
источник

ΙΤ

Ιωάννης Τσεκούρι in QA — Load & Performance
Сделаем попозже, планируем это докладом рассказать
источник

СЧ

Сергей Чепкасов in QA — Load & Performance
Надеюсь что контейнеры тоже успею подготовить к докладу)
источник

KY

Kirill Yurkov in QA — Load & Performance
Забавная подборка)
источник

KY

Kirill Yurkov in QA — Load & Performance
Открытые бенчмарки для нагрузочного тестирования серверов и веб-приложений. Это — подборка утилит, составленная на основе рекомендаций резидентов Hacker News и GitHub. В список вошли Locust, Vegeta, Slow_cooker, k6 и Siege: https://t.co/mcyno66JQQ https://t.co/hZSoi8ScRt
источник

И

Июля in QA — Load & Performance
Ура, решили мою проблему. Для анализа запросов к БД воспользовалась solarwinds. Но оказалось, что проблема не в базе. Всё же пришлось замучать админа и по логам разобраться что к чему. Вроде как количество запросов было больше лимита (какая-то настройка в .net core). Админ в конфиге приложения поменял max pool size со  100 на 2000 и тесты заработали. Но у меня не хватило знаний, чтобы разобраться самой :( Хорошо, что у меня крутой админ-девопс.
источник

И

Июля in QA — Load & Performance
Но теперь у меня есть список тулзов и возможностей sql для настройки крутого мониторинга, которые вы советовали
источник

И

Июля in QA — Load & Performance
У меня ещё вопрос. Может, кто знает почему у моих графиков "провалы в памяти" ))))
источник

И

Июля in QA — Load & Performance
источник

AK

Alexander Koptyaev in QA — Load & Performance
Привет, вопрос по базисному термину, на который не отыскал детального объяснения в чатике и первой странице гугла:
что из себя представляет VU (virtual user) с точки зрения клиентской и серверной машинки, а также взаимодействия клиент-сервер?
Или же зависит от используемого протокола и/или фреймворка нагрузки?

Вводные данные:
фреймворк/инструмент: k6, http-запросы.

Профили нагрузки:
1) rps:1; vus:1; на энное кол-во минут — в графане вижу, что увеличение кол-ва запросов действительно минимально: + ~1rps. Всё хорошо;
2) rps:1; vus: 1..1000 с разгоном в течение энного кол-ва минут — вижу, что нагрузка увеличилась на ~+100rps в пике, хотя по документации k6 опция "rps" —  "The maximum number of requests to make per second, in total across all VUs" , т.е.  вместо ~+100rps ожидал увидеть нагрузку в ~1rps, по аналогии с опытом №1
— т.е. либо баг k6, что лимит по rps ошибочно не учитывает сумму rps по всем потокам VUs, либо же скрытое законное поведение для VUs, необходимое для существования каждого VU.

Куда копать и что почитать о тонкостях сущности VU?
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Alexander Koptyaev
Привет, вопрос по базисному термину, на который не отыскал детального объяснения в чатике и первой странице гугла:
что из себя представляет VU (virtual user) с точки зрения клиентской и серверной машинки, а также взаимодействия клиент-сервер?
Или же зависит от используемого протокола и/или фреймворка нагрузки?

Вводные данные:
фреймворк/инструмент: k6, http-запросы.

Профили нагрузки:
1) rps:1; vus:1; на энное кол-во минут — в графане вижу, что увеличение кол-ва запросов действительно минимально: + ~1rps. Всё хорошо;
2) rps:1; vus: 1..1000 с разгоном в течение энного кол-ва минут — вижу, что нагрузка увеличилась на ~+100rps в пике, хотя по документации k6 опция "rps" —  "The maximum number of requests to make per second, in total across all VUs" , т.е.  вместо ~+100rps ожидал увидеть нагрузку в ~1rps, по аналогии с опытом №1
— т.е. либо баг k6, что лимит по rps ошибочно не учитывает сумму rps по всем потокам VUs, либо же скрытое законное поведение для VUs, необходимое для существования каждого VU.

Куда копать и что почитать о тонкостях сущности VU?
От инструмента зависит
источник

KY

Kirill Yurkov in QA — Load & Performance
k6, насколько я понял
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Могу пример привести для JMeter. Там можно ставить таймер, ограничивающий интенсивность.

Правильно ставить его на первый запрос. Но часто люди ставят его после последнего запроса.

Приводит это к тому, что если виртуальные пользователи запускаются в количестве 1000 за минуту (разгон). То сначала они без пауз отправляют запросы. Интенсивность отправки первого запроса будет примерно постоянной: 1000 запросов/60 сек ~ 17 в сек.

Интенсивность отправки второго будет зависеть от того, как долго будет обрабатываться ответ на первый. Будет ли это время постоянным
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
И ещё замечание. Инструменты контролируют интенсивность отправки запросов.

Графики сторонние (на стороне сервера) могут отобтражать интенсивность отправки ответов на полученные запросы. И эти интенсивности могут не совпадать
источник

AV

Andrey Vasiliev in QA — Load & Performance
Июля
обычно такое свидетельствует о падении приложения которое отдает метрики или самого сервиса
источник

AV

Andrey Vasiliev in QA — Load & Performance
Andrey Vasiliev
обычно такое свидетельствует о падении приложения которое отдает метрики или самого сервиса
то время когда приложения самовостанавливается оно не отдает метрики по этому и провал
источник

AK

Alexander Koptyaev in QA — Load & Performance
Вячеслав Смирнов
Могу пример привести для JMeter. Там можно ставить таймер, ограничивающий интенсивность.

Правильно ставить его на первый запрос. Но часто люди ставят его после последнего запроса.

Приводит это к тому, что если виртуальные пользователи запускаются в количестве 1000 за минуту (разгон). То сначала они без пауз отправляют запросы. Интенсивность отправки первого запроса будет примерно постоянной: 1000 запросов/60 сек ~ 17 в сек.

Интенсивность отправки второго будет зависеть от того, как долго будет обрабатываться ответ на первый. Будет ли это время постоянным
если под таймером понимается тайм-аут (wait), то устанавливаю его в случайном размере, перед первым запросом и после последнего запроса в сценарии;
по мониторингу — слишком большие различия по кол-ву запросов между двумя профилями нагрузки, которые должны были выдать примерно идентичные данные.

В любом случае спасибо, если откопаю что-то ещё полезное в решении — для истории кину в чатик
источник

И

Июля in QA — Load & Performance
Andrey Vasiliev
то время когда приложения самовостанавливается оно не отдает метрики по этому и провал
Блин. Нехорошо как-то. Присмотрюсь к северным метрикам на этот интервал времени. Благодарю!
источник

KY

Kirill Yurkov in QA — Load & Performance
Если метрика собирается телеграфом например - у него тоже есть лог)
источник

O

Oleg in QA — Load & Performance
Alexander Koptyaev
Привет, вопрос по базисному термину, на который не отыскал детального объяснения в чатике и первой странице гугла:
что из себя представляет VU (virtual user) с точки зрения клиентской и серверной машинки, а также взаимодействия клиент-сервер?
Или же зависит от используемого протокола и/или фреймворка нагрузки?

Вводные данные:
фреймворк/инструмент: k6, http-запросы.

Профили нагрузки:
1) rps:1; vus:1; на энное кол-во минут — в графане вижу, что увеличение кол-ва запросов действительно минимально: + ~1rps. Всё хорошо;
2) rps:1; vus: 1..1000 с разгоном в течение энного кол-ва минут — вижу, что нагрузка увеличилась на ~+100rps в пике, хотя по документации k6 опция "rps" —  "The maximum number of requests to make per second, in total across all VUs" , т.е.  вместо ~+100rps ожидал увидеть нагрузку в ~1rps, по аналогии с опытом №1
— т.е. либо баг k6, что лимит по rps ошибочно не учитывает сумму rps по всем потокам VUs, либо же скрытое законное поведение для VUs, необходимое для существования каждого VU.

Куда копать и что почитать о тонкостях сущности VU?
Virtual user это тред на клиенте. В зависимости от настроек тулы, они могут создавать новые коннекшены или утилизировать существующие. С точки зрения сервера есть только коннекшены и запросы. Это так, в теории.
источник