Ну вот поэтому в кайте через селениум грузит

Я, кстати, думал не держать соединение, а отдельно продьюсе, отдельно консьюмер

Да, также делаю

https://t.me/qaload/20
Вот тут описал подход для замера времени с момента отправки запроса в одном потоке до момента получения в другом потоке

Слайды к докладу Готовим тестовые данные и сервируем отчёт по тестированию производительности (30 мая 2020 года), который был на недавно прошедшем CodeFest Online. Отличная получилась конференция. Рекомендую посетить следующую конференцию уже в Новосибирске:
— осень: 24-25 октября или 31 октября-1 ноября этого года;
— весна 27-28 марта 2021.

Рассказ об особенностях подготовки тестовых данных для тестов производительности новых микросервисов в банке. Поделился наработками по генерации тестовых данных в PostgreSQL и их влиянии на результат тестирования. Рассказал, что включить в отчёт по тестированию производительности и как донести результаты до команды.

Доклад будет интересен инженерам по тестированию производительности, показываю, как нашел 40% багов. И всем будет интересно, как ускорить написание отчётов минимум на день.

Сообщество инженеров по тестированию производительности:
@qaload (канал) / @qa_load (чат)

Видосики будут?

Спасибо

Думаю будут тут: https://www.youtube.com/user/codefestru
Скорее всего к моменту следующей конференции.

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

Так попробовал примерить знания полученные от Кирилла Анастасина по подготовке презентаций, про которого узлах из школы докладчиков @Russia4_SpeakersSchool

Раньше были пожелания по текущему чату - сделать удобным поиск. Что сейчас искать неудобно.

Сделал выгрузку архива чата в HTML. Ссылаться на сообщения можно теперь так:
https://qaload.github.io/qa_load/messages21.html#go_to_message21105

Получилось довольно много сообщений, у нас активное сообщество. Выгрузил сообщения с ноября 2018 года:

 1. 07.11.2018 — 22.01.2019
 2. 22.01.2019 — 15.03.2019
 3. 15.03.2019 — 27.04.2019
 4. 27.04.2019 — 13.06.2019
 5. 13.06.2019 — 16.07.2019
 6. 16.07.2019 — 01.10.2019
 7. 01.10.2019 — 22.08.2019
 8. 22.08.2019 — 13.09.2019
 9. 13.09.2019 — 03.10.2019
10. 03.10.2019 — 16.10.2019
11. 16.10.2019 — 07.11.2019
12. 07.11.2019 — 04.12.2019
13. 04.12.2019 — 20.12.2019
14. 20.12.2019 — 14.01.2020
15. 14.01.2020 — 26.01.2020
16. 26.01.2020 — 11.02.2020
17. 11.02.2020 — 27.02.2020
18. 27.02.2020 — 19.03.2020
19. 19.03.2020 — 07.04.2020
20. 07.04.2020 — 24.04.2020
21. 24.04.2020 — 10.05.2020
22. 10.05.2020 — 22.05.2020
23. 22.05.2020 — ...

Концепт сделан вручную. В дальнейшем автоматизирую.

Цели:
1. Сделать бекап/архив чата
2. Облегчить индексацию поисковыми системами, ускорить поиск
3. Облегчить доступ читателям, у которых нет telegram или доступа к telegram

Классную штуку нашёл в графане - можно переиспользовать результаты тяжёлых запросов, если они нужны вам в разных представлениях.
Например у меня есть график TPS и времён отклика а рядом итоги тех же данных но в виде таблицы, где данные сагрегированы за весь период теста.

https://www.youtube.com/watch?v=qWuT3YEGzUA

Так вот она для чего. Спасибо! А я её неверно понял. Подумал, что вот в таком случае будет удобной:
Есть большая-большая доска, в которой множество скрытых блоков: по серверу базы данных, по серверу приложений, по ошибкам, ... по всему.
В ходе тестирования выясняется, что только 7 графиков заслуживают внимания.
И эти 7 графиков решаю скопировать в новый блок. И смотреть на них близко. Без скроллов.

На практике столкнулся с рядом ограничений:
0. Надо чтобы была доска с большим количеством панелей, которые уже тяжело скроллить.
1. Надо чтобы все панели имели хорошие имена. Иначе из потом их сложно выбрать.
2. Не работает для динамических Repeat-панелей.

И перестал использовать.
Спасибо, Витя

Кстати, есть удобные способы анализировать ошибки, проявившиеся в ходе теста Jmeter?
Что есть: в Grafana вижу, что завалились 15% операций.
А причины - не вижу. То, что Jmeter передаёт через backendListner - бесполезная фигня.
Можно анализировать лог жметра, но если нам нужны ответы с сообщениями об ошибках - лог должен быть в xml, а вы знаете, как это классно - читать xml на пару мегабайт.

у Серпутко есть jsr223-листнер, который, вроде, умеет передавать в influx сами ошибки, но он требует установленной галочки "Create parent sempler", а с ней увеличивается расход памяти. Но я уже думаю перейти на этот вариант.

Чего хочется:
Что бы к логи тоже складывались в хранилище, откуда можно было читать информацию в Grafana, фильтруя по $TimeFilter или тредгруппам / транзакциям.

Вроде напрашивается передача логов в Elastic или парсинг их и передача в графану.

Но может уже есть готовые решения, что бы не пилить свои велосипеды?

Но ведь мы рассказывали про это на перфконф

на последней? мне пришлось уйти с середины, к сожалению :(

Ну видосы есть

там с видосами боль

Наверное на платной конференции то должны остаться видосы

в общем, если поделишься идеей и слайдами - буду очень благодарен

Идеи в общем то никакой нет