B
пока непонятно
надо почитать
надо почитать
Size: a a a
2020 March 19
ΙΤ
тестили с помощью него Janus
B
так он поднимает реальные браузеры?
AG
советую полностью переходить на vars.put и props.put - лишает проблем с переменными абсолютно и навсегда
Да при необходимости я так и делаю)
ΙΤ
так он поднимает реальные браузеры?
да там вроде драйвер селениумовский
B
а нет такого способа - прямыми запросами тестить? что-то не охота поднимать 100 инстансов ) реального браузера
ΙΤ
WebRTC (англ. real-time communications — коммуникации в реальном времени) — проект с открытым исходным кодом, предназначенный для организации передачи потоковых данных между браузерами или другими поддерживающими его приложениями по технологии точка-точка.
ΙΤ
между браузерами
ΙΤ
наверняка можно сэмулировать браузер конечно, но трудозатраты совсем другие
B
то есть на каждый тест - поднимается два инстанса
для сотни видео звонков - нужно 200 браузеров поднять
любопытно. дадут ли мне ресурсы на это все
для сотни видео звонков - нужно 200 браузеров поднять
любопытно. дадут ли мне ресурсы на это все
ΙΤ
то есть на каждый тест - поднимается два инстанса
для сотни видео звонков - нужно 200 браузеров поднять
любопытно. дадут ли мне ресурсы на это все
для сотни видео звонков - нужно 200 браузеров поднять
любопытно. дадут ли мне ресурсы на это все
не обязательно чтобы 1 поток 1 брузер, можно играться с этим
B
не обязательно чтобы 1 поток 1 брузер, можно играться с этим
а он умеет в хэдлесс?
наверное глупый вопрос )
наверное глупый вопрос )
VS
Alex Grishutin
Вообще, было бы круто сделать из этой вещи фичу, для нормальной шары переменных между тредгруппами 😂😂
Граждане, не проходим мимо, заводим тикеты: https://bz.apache.org/bugzilla/describecomponents.cgi?product=JMeter
ВС
Немножко нубский вопрос по методологии локализации проблем с перфомансом:
Допустим, простенькие нагрузочные тесты определили, что в новой фиче закралось нечто, сильно аффектящее перфоманс. Как вы дальше поступаете? Сразу идете к разрабам? Локализуете проблему максимально на уровне API? Закатываете рукава и ковыряетесь с профайлером чтобы ткнуть девов в конкретное место в коде?
Допустим, простенькие нагрузочные тесты определили, что в новой фиче закралось нечто, сильно аффектящее перфоманс. Как вы дальше поступаете? Сразу идете к разрабам? Локализуете проблему максимально на уровне API? Закатываете рукава и ковыряетесь с профайлером чтобы ткнуть девов в конкретное место в коде?
ВС
Допустим, разрабы при указании на проблемы с перфомансом в новой фиче в целом задумчиво чешут затылок. Что вы делаете в этой ситуации, и где заканчивается сфера ответственности нагрузочника и начинается разработчика?
ВС
Если проект совсем новый и идёт активная разработка,
то разработчик уже сам знает, что у него полно технического долга,
и держит весь код в голове.
Разработчку достаточно знать какой из методов самый медленный.
И он сосредоточится на его рефакторинге.
Дефекты в этом случае очевидные.
Когда писал свои рекомендации для новых проектов, то разработчики на них смотрели, но исправляли по своему.
А когда проект устоявщийся, сложный, и разработчик уже не держит в голове контекст.
То профилирование нужно и необходимо.
Если дефект проявляется только на тестовом стенде.
Если для запуска тестов (для воспроизведения) нужно сделать много сложных шагов.
То очевидно, что вся работа по профилированию и рекомендациям по исправлению - на инженере по производительности.
Если есть возможность написать простой тест для разработчика.
Чтобы он мог запустить его и сам всё воспроизвести, то лучше передать разработчику.
Мы старатеся писать тест для разработчика с протым профилем - один поток и 100/1000 повторений.
Такой тест удобно отлаживать, разработчик может поставить точку останова в коде и всё остановится (второго потока теста нет).
А критерием скорости является суммарная длительность выполнения 1000 повторений.
Тесты пишем на JMeter и Gatling, параметризированные.
Поэтому они могут и на localhost разработчика подавать нагрузку и на нагрузочный стенд.
У разработчика просто одна команда для запуска, консольная.
И ещё так сложилось, что SQL запросы, индексы, ... почти всегда правим сами.
У нас самые большие базы данных на стендах. А у разработчиков базы данных пустые, им сложнее.
то разработчик уже сам знает, что у него полно технического долга,
и держит весь код в голове.
Разработчку достаточно знать какой из методов самый медленный.
И он сосредоточится на его рефакторинге.
Дефекты в этом случае очевидные.
Когда писал свои рекомендации для новых проектов, то разработчики на них смотрели, но исправляли по своему.
А когда проект устоявщийся, сложный, и разработчик уже не держит в голове контекст.
То профилирование нужно и необходимо.
Если дефект проявляется только на тестовом стенде.
Если для запуска тестов (для воспроизведения) нужно сделать много сложных шагов.
То очевидно, что вся работа по профилированию и рекомендациям по исправлению - на инженере по производительности.
Если есть возможность написать простой тест для разработчика.
Чтобы он мог запустить его и сам всё воспроизвести, то лучше передать разработчику.
Мы старатеся писать тест для разработчика с протым профилем - один поток и 100/1000 повторений.
Такой тест удобно отлаживать, разработчик может поставить точку останова в коде и всё остановится (второго потока теста нет).
А критерием скорости является суммарная длительность выполнения 1000 повторений.
Тесты пишем на JMeter и Gatling, параметризированные.
Поэтому они могут и на localhost разработчика подавать нагрузку и на нагрузочный стенд.
У разработчика просто одна команда для запуска, консольная.
И ещё так сложилось, что SQL запросы, индексы, ... почти всегда правим сами.
У нас самые большие базы данных на стендах. А у разработчиков базы данных пустые, им сложнее.
O
Даже если нужно будет профилировать, нет смысла скрывать промежуточные результаты. Главное что бы не было ошибок не связанных с приложением
O
Ну а что делать дальше наверно вместе с разработчиком сможете решить...
ВС
Если проект совсем новый и идёт активная разработка,
то разработчик уже сам знает, что у него полно технического долга,
и держит весь код в голове.
Разработчку достаточно знать какой из методов самый медленный.
И он сосредоточится на его рефакторинге.
Дефекты в этом случае очевидные.
Когда писал свои рекомендации для новых проектов, то разработчики на них смотрели, но исправляли по своему.
А когда проект устоявщийся, сложный, и разработчик уже не держит в голове контекст.
То профилирование нужно и необходимо.
Если дефект проявляется только на тестовом стенде.
Если для запуска тестов (для воспроизведения) нужно сделать много сложных шагов.
То очевидно, что вся работа по профилированию и рекомендациям по исправлению - на инженере по производительности.
Если есть возможность написать простой тест для разработчика.
Чтобы он мог запустить его и сам всё воспроизвести, то лучше передать разработчику.
Мы старатеся писать тест для разработчика с протым профилем - один поток и 100/1000 повторений.
Такой тест удобно отлаживать, разработчик может поставить точку останова в коде и всё остановится (второго потока теста нет).
А критерием скорости является суммарная длительность выполнения 1000 повторений.
Тесты пишем на JMeter и Gatling, параметризированные.
Поэтому они могут и на localhost разработчика подавать нагрузку и на нагрузочный стенд.
У разработчика просто одна команда для запуска, консольная.
И ещё так сложилось, что SQL запросы, индексы, ... почти всегда правим сами.
У нас самые большие базы данных на стендах. А у разработчиков базы данных пустые, им сложнее.
то разработчик уже сам знает, что у него полно технического долга,
и держит весь код в голове.
Разработчку достаточно знать какой из методов самый медленный.
И он сосредоточится на его рефакторинге.
Дефекты в этом случае очевидные.
Когда писал свои рекомендации для новых проектов, то разработчики на них смотрели, но исправляли по своему.
А когда проект устоявщийся, сложный, и разработчик уже не держит в голове контекст.
То профилирование нужно и необходимо.
Если дефект проявляется только на тестовом стенде.
Если для запуска тестов (для воспроизведения) нужно сделать много сложных шагов.
То очевидно, что вся работа по профилированию и рекомендациям по исправлению - на инженере по производительности.
Если есть возможность написать простой тест для разработчика.
Чтобы он мог запустить его и сам всё воспроизвести, то лучше передать разработчику.
Мы старатеся писать тест для разработчика с протым профилем - один поток и 100/1000 повторений.
Такой тест удобно отлаживать, разработчик может поставить точку останова в коде и всё остановится (второго потока теста нет).
А критерием скорости является суммарная длительность выполнения 1000 повторений.
Тесты пишем на JMeter и Gatling, параметризированные.
Поэтому они могут и на localhost разработчика подавать нагрузку и на нагрузочный стенд.
У разработчика просто одна команда для запуска, консольная.
И ещё так сложилось, что SQL запросы, индексы, ... почти всегда правим сами.
У нас самые большие базы данных на стендах. А у разработчиков базы данных пустые, им сложнее.
спасибо за подробный ответ
OP
советую полностью переходить на vars.put и props.put - лишает проблем с переменными абсолютно и навсегда
Абсолютно согласен с вами. Но в UDV у меня были указаны изна предустановленная переменная, как дефолт