Size: a a a

QA — Load & Performance

2020 September 30

ВС

Вячеслав Смирнов... in QA — Load & Performance
Хочу поделиться пока недокументированной возможностью настройки #Flux datasource в Grafana 7.2.0 к InfluxDB 1.8.2 через yml-файлы (механизм Provisioning):
/provisioning/datasources/flux.yml

apiVersion: 1

datasources:
 - name: Flux
   type: influxdb
   access: proxy
   url: http://metrics:8086
   database: telegraf
   basicAuth: true
   basicAuthUser:
   basicAuthPassword:
   withCredentials: false
   isDefault: false
   jsonData:
     defaultBucket: 'telegraf'
     httpMode: 'POST'
     organization: '1'
     version: 'Flux'
   secureJsonData:
     token: 1
   version: 1
   editable: false

Недокументированными являются параметры из секции jsonData. С ними подключить Flux можно и через Provisioning
источник

D

Denis in QA — Load & Performance
Вячеслав Смирнов
или таймер ограничивает rps
в самом тесте имеешь ввиду, throughput timer? если да, то там его нет - тест максимально прост, Ultimate Thread Group и в нем Http Request Sampler
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Denis
хотя адрес на localhost я не менял..
Я бы проверил снова HTTP Request Defaults. что там стоит. Нет ли там MD5 галочки, например, прокси, других настроек странных
Посмотрел бы на опцию в jmeter.properties
httpclient.socket.http.cps = 0
httpclient.socket.https.cps = 0
убедлся бы, что они 0-лю равны
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Посмотрел бы на логирование. Нет ли XML лога в сетевую папку. Или еще что-то такое незаметное
источник

D

Denis in QA — Load & Performance
хорошо. спасибо, все перепроверю
источник

VG

Viktor Ganeles in QA — Load & Performance
Denis
Добрый день!

Запускаю тест в jmeter, но упираюсь в порог 15 rps, время отклика почти не меняется, ошибки растут но совсем незначительно.
Подскажите куда копать чтобы преодолеть этот лимит запросов

Сам скрипт состоит из одного post-запроса,
Что уже пробовал:
1. Пробовал менять httpclient.reset_state_on_thread_group_iteration=false
2. use keep alive
У меня был такой кейс:
- при увеличении нагрузки рост производительности в момент Х практически останавливался, при этом времена отклика не увеличивались, а ошибок было 1-2%

Проблема оказалась всё-таки в ошибках:

Времена отклика пассов не увеличивались, а вот ВРЕМЕНА ОТКЛИКА ОШИБОК увеличивались очень сильно.

Таким образом даже небольшое количество ошибок приводило к значительному снижению производительности.
источник

D

Denis in QA — Load & Performance
Viktor Ganeles
У меня был такой кейс:
- при увеличении нагрузки рост производительности в момент Х практически останавливался, при этом времена отклика не увеличивались, а ошибок было 1-2%

Проблема оказалась всё-таки в ошибках:

Времена отклика пассов не увеличивались, а вот ВРЕМЕНА ОТКЛИКА ОШИБОК увеличивались очень сильно.

Таким образом даже небольшое количество ошибок приводило к значительному снижению производительности.
хм, кстати возможно, посмотрю в эту сторону, спасибо за наводку
источник

KY

Kirill Yurkov in QA — Load & Performance
Denis
да, плавно повышается с 2 до 40 и примерно, с 2 до 4 потоков все ок, видно как время отклика увеличилось ~ 200ms, но дальше там и остается примерно
ну поставь 200 сразу без плавно
источник

S7

Sam 7 in QA — Load & Performance
Sam 7
почему то таски выполняются в 3 потока, и не создаются новые
я свою проблему решил - ответ в new LinkedBlockingQueue<Runnable>(1)
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Интересно. Получается если очередь не null но пустая, то параллельность минимальная. В документации нет описания работы при разном размере:

workQueue - the queue to use for holding tasks before they are executed. This queue will hold only the Runnable tasks submitted by the execute method.
источник

S7

Sam 7 in QA — Load & Performance
теперь столкнулся с другой проблемой. если очередь не пустая, а кол-во тасок больше очереди и макс пул сайз, то получаю эксепшн java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@6df97b55 rejected from java.util.concurrent.ThreadPoolExecutor@3cbbc1e0[Running, pool size = 500, active threads = 500, queued tasks = 0, completed tasks = 22]
источник

D

Denis in QA — Load & Performance
Viktor Ganeles
У меня был такой кейс:
- при увеличении нагрузки рост производительности в момент Х практически останавливался, при этом времена отклика не увеличивались, а ошибок было 1-2%

Проблема оказалась всё-таки в ошибках:

Времена отклика пассов не увеличивались, а вот ВРЕМЕНА ОТКЛИКА ОШИБОК увеличивались очень сильно.

Таким образом даже небольшое количество ошибок приводило к значительному снижению производительности.
в итоге так и было..
источник

VG

Viktor Ganeles in QA — Load & Performance
Denis
в итоге так и было..
Ура, рад, что помог :)
источник
2020 October 01

S

Slip in QA — Load & Performance
Всем привет. У кого есть опыт нагрузки websocket'a с помощью Gatling'a?
источник

g

gat0r in QA — Load & Performance
Есть опыт, да
источник

OK

Oleksandr Khotemskyi in QA — Load & Performance
Коллеги добрый день.
Готовлюсь пускать нагрузку на бекенд (k6.io), но практически все ендпоинты за авторизацией. Подскажите какие есть варианты ? Создавать юзера каждый раз в начале сценария? Заготовить какой то пулл юзеров? А как узнать сколько юзеров заготовить? Посоветуйте как вы пускаете нагрузку в таких случаях?
источник

OK

Oleksandr Khotemskyi in QA — Load & Performance
Юзать одного юзера не вариант - множественные логины запрещены бекендом. Можно попробовать подсовывать всем один токен, но чет как то хз…
источник

M

Maxim in QA — Load & Performance
Заготовить, конечно.
Статическая нагрузка на БД в виде реального количества записей в пользовательских таблицах при нагрузочном тестировании не лишнее.
источник

OK

Oleksandr Khotemskyi in QA — Load & Performance
Maxim
Заготовить, конечно.
Статическая нагрузка на БД в виде реального количества записей в пользовательских таблицах при нагрузочном тестировании не лишнее.
понял, принял, спасибо
источник

M

Maxim in QA — Load & Performance
Пул пользаков в тестовой среде обычно в процессе жизни функционала в проме приходится увеличивать итерационно.
источник