а платное провоить низя...NDA и всё такое

Коллеги, может кто обращал внимание, зависит ли скорость работы Jmeter от количества подключаемых внешних jmx-файлов через include controller. Или такой архитектуры желательно избегать. Ведь может быть ситуация, когда подключаемый jmx содержит в себе тоже подключаемый jmx через include controller.

В теории, скорость не должна зависеть

Хороший опыт. И успешный, по факту.

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

А занятие это интересное

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

Про успешность пока рано говорить...день Х будет в пятницу)) опыт в целом состоялся благодаря Вам и чату во многом и всем тем людям, которые пишут статьи и снимают мануалы) спустя полгода работы вчера внезапно осознала что начала понимать англоговорящих индусов на обычной скорости воспроизведения))) нагрузочное -  занятие интересное, согласна)  и на уровне Jmetra и умения читать отчеты - любому тестировщику, стремящемуся к развитию пригодится.  На текущем месте - это никому не нужно, до вот таких внезапных "петухов". Интернет-магазинам по большей части это не нужно и клиенты за это не готовы платить.  Я вот в сентябре собиралась на конфу...но с текущем положением пришлось вернуть билеты, так как неизвестно что будет завтра.

@Galakeit
Так как теперь есть стенд, то можно оценить полноту кеширования, скорость загрузки главной страницы простыми инструментами

https://www.webpagetest.org/
https://developers.google.com/speed/pagespeed/insights/?hl=RU

Добрый день. У меня на проект реализован на микросервисах и общение клиента с сервисами сделан через gateway. На прямую с сервисами я общаться не могу,  поэтому запросы отправляю на gateway, а он уже общается с нужным сервисом. Как итог респонс который я получаю - это сумма работы gateway и самого сервиса (как я понял). Но у меня есть требование мерять как быстро отрабатывает и сервис и gateway по отдельности. Скажите, у кого может были такие задачи, как вы меряли? Или может можно попросить разрабов добавить какието логи и тогда уже както обрабатывать логи?

просил разрабов айпишники чтоб грузить в обход гейтвея

В логах gateway время ответа сервера будет, отдельно от времени обработки всего запроса. Сужу по nginx и haproxy.

https://github.com/aragozin/loadlab_vm/blob/master/ansible/deployment/roles/nginx/files/telegraf.d/enginx.conf

Для nginx можно логи визуализировать так
В репозитории Алексея есть и Grafana-доска

Не хорошо, как то не ответил, но настроения не было)
Вопрос мой был
1. Может быть кто знает что обозначает resource loading на вкладке perfomance devTools в google chrome?
Мое предположение, что это обработка на клиенте js файла (в данном случае js из cache).
Ответ
1.Судя по оф доку это "время ожидания главного потока", что бы это не значило
Об этом написано вот тут https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/

Исходя из ответа у меня только Предположение не подкрепленное практикой. Да и для практике надо свой сайт сделать или общение с разработчиком.
Как понимаю есть основной(main) поток, в которой работает браузер и который явно влияет на usability и дочерние (возможно например ajax).
https://stackoverflow.com/questions/36483032/what-is-threads-in-the-source-panel
resource loading - это время занятости основного потока, время обработки фронтом данного js после его загрузки (возможно в данном js есть инициализация которая долго выполняется)

Вопрос возник по организационно-бюрократическим причинам.
Необходимо было, что то завести на долгий фронт и бэк, что бы "были довольны".
На случай, если опять будет задача придумать причины почему мы не виноваты в фронте (и я думаю мы не виноваты). Я попросил коллегу выписать и это время, а объяснения если вдруг спросят придумаю потом, но не спросили.

>Необходимо было, что то завести на долгий фронт и бэк, что бы "были довольны".
не понял если честно

Еще если есть желание и время настроить zipkin. В нем можно отследить время запросов между любыми сервисами.
Но
1) явно дольше чем предложение выше

2) видел такое на проекте, НО не знаю, насколько данный момент мониторили, возможно есть подводные камни.

Возможно, люди в чате знают + и - такого варианта?

3) как-то от разработчика слышал Мы узнали про zipkin, внедрили его на прошлом проекте сразу в прод и сожрало все ресурсы сервера, давай откатывать по быстрому. Нагрузочных тестов на проекте не было и падение было не страшно. Удобная штука, удобно дебажить, можно не только время общения между сервисами смотреть, но и любую отладочную инфу к запросу прикручивать.
https://zipkin.io/

Изначально вопрос возник по организационно-бюрократическим причинам.
Задача:
1) Завести багу на долгий фронт
2) Придумать объяснение, что виноваты не разработчики)). Что бы придумать объяснение и оно было логичное почитал про performance в devTools. Поэтому возник вопрос.
Почему это делал нагрузчик? Потому что разработчики все заняты, они ничего не успевают сделать. Через разработчиков писать обоснование неделя переписок и много раздражения от менеджеров. Это же время, производительность, значит делают нагрузчики.

Так понятнее?

Придумать объяснение, что виноваты не разработчики подрядчика

Понятнее, только не понятно почему не виноваты разработчики. Если еще будут такие задачи посмотрите в сторону апишки Performance Timing и Navigation Timing. Были случаи когда юзеры жаловались что страницы по минуте грузятся, подняли мониторинг и оказалось что они с 2г в лесу сидят :)

Виноваты разработчики, но не те на стороне которых я, а те которые делали библиотеки для фронта (они из другой команды)

понял. спасибо)