Size: a a a

QA — Load & Performance

2020 January 16

KY

Kirill Yurkov in QA — Load & Performance
Оно умеет работать по SSL и TLS
источник

KY

Kirill Yurkov in QA — Load & Performance
хост и порт SMTP сервера
источник

KY

Kirill Yurkov in QA — Load & Performance
если тчо)
источник

SM

Ser Menzelson in QA — Load & Performance
Несколько новых терминов, Спасибо! Этот сервис генерит однообразные сообщения для имитации нагрузки как я понял?
источник

KY

Kirill Yurkov in QA — Load & Performance
так, Jmeter это средство для нагрузки, оно посылает запросы такие какие ты ему скажешь. Можно одинаковые, разные и тд.
источник

KY

Kirill Yurkov in QA — Load & Performance
SMTP это протокол почты
источник

KY

Kirill Yurkov in QA — Load & Performance
Sampler это элемент в Jmeter, который осуществляет отправку
источник

W

Wazicar in QA — Load & Performance
Sam 7
У этого есть какое то обоснование?
Это по определению стандартного нормального (Гауса) распределения. Должно быть. Если это не так, то распределение какое-то другое, и нельзя уже всякие свойства его использовать в рассуждениях и прогнозах. А поскольку статистика вся почти на этом распределение основана, то всё под него пытаются подогнать, потому что с другими распределениями непонятно что делать
источник

ΙΤ

Ιωάννης Τσεκούρι in QA — Load & Performance
я всё видел @andrey_s_filatov
источник

ВС

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

Есть проблема, что в выпадающих списках Grafana, может быть очень много данных. Если не применять фильтрацию по времени.

И простой способ применить фильтр по времени выглядит так:

SHOW TAG VALUES FROM "gatling" WITH KEY = "simulation" WHERE $timeFilter

При применении Query options / Refresh = On Time Range Change.

Но у этого способа есть недостаток. SHOW TAG VALUES применяет фильтр по $timeFilter, округляя его до размера InfluxDB Shard.
Некоторое время назад советовал даже уменьшить временной интервал Shard для большой точности. В результате @login40k потерял историю данных InflxuDB, так как шарды пересоздались.

Есть безопасный способ сократить длину фильтра. Для этого понадобится просто переписать запрос выбора значений. Не меняя настройки InfxluDB:

SELECT "simulation" FROM (SELECT last("mean") FROM "gatling" WHERE $timeFilter GROUP BY "simulation")


Тут выбирается измерение, в котором есть нужный тег и большое количество точек ("gatling"). Выбирается поле, которое заполнено для всех точек ("mean"). Значения поля группируются по нужному тегу, берётся только последнее значение для тега, а далее из результатов выводится только сам тег.

Это позволяет сделать выпадающий список только с теми значениями, что точно соотвествуют выбранному интервалу времени в Grafana.
источник

AK

Anton Kramarev in QA — Load & Performance
Если нету ошибаюсь, то таймфильтр к SHOW TAG VALUES не применяется вообще
источник

AK

Anton Kramarev in QA — Load & Performance
Боролся с этим, но в документации написано что нет
источник

AK

Anton Kramarev in QA — Load & Performance
А вот хак со вторым селектом надо себе сохранить
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Думаю, применяется. К SHOW MEASUREMENT не применяется точно.
источник

A

Artyom in QA — Load & Performance
Мы было уже поднимали с @smirnovqa этот вопрос)
источник

A

Artyom in QA — Load & Performance
Действительно применяется по шарду
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
У SHOW TAG VALUES есть особенность, что запрос выполняется не к данным, а к индексу по данным. И если сделать так, что из базы данных удалить вообще все значения по нужному тегу. То в выпадающем списке они будут видны. Но до перезапуска сервера InfluxDB или пересборки его индексов.

А временной фильтр на него накладывается.
источник

AK

Anton Kramarev in QA — Load & Performance
Теги и есть индекс
источник

ВС

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

AK

Anton Kramarev in QA — Load & Performance
Ну вернее его аналог в инфлаксе
источник