Ⓢ
А, тогда да сорри. Пользователи JMeter - это тестеры и девопсы?
Size: a a a
2019 October 18
Ⓢ
Ну ещё я 5 лет назад базу резюме с Хедхантера пытался скачать с помощью JMeter
SM
Ну в моём представлении да, хотя мейнтейнеру виднее 😀 Может Володя позже вернётся и ответит 😀
SM
Хотя у нас в команде есть пара аналитиков с бекграундом тестировщиков, которые JMeter юзают вместо Postman как GUI клиент к ресту. Но им точно абсолютно пофигу саспенд функция там внутри или какая-то иная 😀
2019 October 19
VS
Как пользователь ощутит это изменение?
А я уже на базовом уровне внедрил, и там всё оочень хорошо: https://lists.apache.org/thread.html/9ca6acdedb03da4e49ed5fdaf44fad770e0467beb3dd4d4913e1f70d@%3Cdev.jmeter.apache.org%3E
Смысл в следующем: JMeter используют для генерации нагрузки обычные потоки.
И очень часто нагрузка должна быть осмысленная. Т.е. не просто нужно молотить непрерывно, а важно делать паузы между запросами, эмулируя действия реального пользователя, который иногда думает между кликами (по 5-10 секунд запросто).
Получается, если мы заходим эмулировать нагрузку от 50’000 условных пользователей, то в обычном JMeter’е нужно 50’000 тредов. И, да, большую часть времени эти потоки будут спать в sleep’ах.
В случае корутин же столько потоков не нужно. Да, «локальное состояние каждого псевдо-потока хранить всё равно нужно». Но вот тредов нужно меньше.
Что я и сделал: впилил корутины в JMeter и на тесте в 100’000 «потоков с паузами по 1сек» он прямо в JMeter UI показывает 97’000 requests/second.
При этом, само подключение корутин заняло меньше дня. Поменял sleep на delay и добавил suspend по вкусу (да, один класс пришлось переписать на Java, но IDEA хорошо сконвертировала).
Потом несложно (надеюсь) будет перейти на асинхронынй HTTP клиент. И тогда «время ответа сервера» тоже не будет требовать «треда на стороне jmeter’а».
С точки зрения «бизнеса» :
1) Можно будет генерировать бОльшую нагрузку с одой нагрузочной машины. Это сильно упрощает написание скриптов и тестирование. Любая схема, когда нужно «запускать нагрузку с N машин, а потом как-то агрегировать логи» сложнее, чем «запустить с одной».
2) Можно будет использовать реалистичные паузы и не упираться в «unable to create native thread».
Как-то так.
Смысл в следующем: JMeter используют для генерации нагрузки обычные потоки.
И очень часто нагрузка должна быть осмысленная. Т.е. не просто нужно молотить непрерывно, а важно делать паузы между запросами, эмулируя действия реального пользователя, который иногда думает между кликами (по 5-10 секунд запросто).
Получается, если мы заходим эмулировать нагрузку от 50’000 условных пользователей, то в обычном JMeter’е нужно 50’000 тредов. И, да, большую часть времени эти потоки будут спать в sleep’ах.
В случае корутин же столько потоков не нужно. Да, «локальное состояние каждого псевдо-потока хранить всё равно нужно». Но вот тредов нужно меньше.
Что я и сделал: впилил корутины в JMeter и на тесте в 100’000 «потоков с паузами по 1сек» он прямо в JMeter UI показывает 97’000 requests/second.
При этом, само подключение корутин заняло меньше дня. Поменял sleep на delay и добавил suspend по вкусу (да, один класс пришлось переписать на Java, но IDEA хорошо сконвертировала).
Потом несложно (надеюсь) будет перейти на асинхронынй HTTP клиент. И тогда «время ответа сервера» тоже не будет требовать «треда на стороне jmeter’а».
С точки зрения «бизнеса» :
1) Можно будет генерировать бОльшую нагрузку с одой нагрузочной машины. Это сильно упрощает написание скриптов и тестирование. Любая схема, когда нужно «запускать нагрузку с N машин, а потом как-то агрегировать логи» сложнее, чем «запустить с одной».
2) Можно будет использовать реалистичные паузы и не упираться в «unable to create native thread».
Как-то так.
VS
У 10’000 тредов есть ещё проблема: если какой-то из потоков захватит блокировку (например, на логгер) и его выгонят с процессора, то все остальные будут ждать «отпускания блокировки», а она не отпустится пока поток не получит управления.
Иными словами, даже, если можно настроить операционку и запустить 10’000 потоков, то проблемы синхронизации между потоками там очень сильно выпирают. А синхронизация нужна: запись файла с результатами, чтение файла с исходными данными и т.п.
Переписать-то можно, но, похоже, эти проблемы перестанут быть проблемами, если применить корутины и сократить количество одновременно выполняющихся потоков до разумного значения.
Иными словами, даже, если можно настроить операционку и запустить 10’000 потоков, то проблемы синхронизации между потоками там очень сильно выпирают. А синхронизация нужна: запись файла с результатами, чтение файла с исходными данными и т.п.
Переписать-то можно, но, похоже, эти проблемы перестанут быть проблемами, если применить корутины и сократить количество одновременно выполняющихся потоков до разумного значения.
SM
А я уже на базовом уровне внедрил, и там всё оочень хорошо: https://lists.apache.org/thread.html/9ca6acdedb03da4e49ed5fdaf44fad770e0467beb3dd4d4913e1f70d@%3Cdev.jmeter.apache.org%3E
Смысл в следующем: JMeter используют для генерации нагрузки обычные потоки.
И очень часто нагрузка должна быть осмысленная. Т.е. не просто нужно молотить непрерывно, а важно делать паузы между запросами, эмулируя действия реального пользователя, который иногда думает между кликами (по 5-10 секунд запросто).
Получается, если мы заходим эмулировать нагрузку от 50’000 условных пользователей, то в обычном JMeter’е нужно 50’000 тредов. И, да, большую часть времени эти потоки будут спать в sleep’ах.
В случае корутин же столько потоков не нужно. Да, «локальное состояние каждого псевдо-потока хранить всё равно нужно». Но вот тредов нужно меньше.
Что я и сделал: впилил корутины в JMeter и на тесте в 100’000 «потоков с паузами по 1сек» он прямо в JMeter UI показывает 97’000 requests/second.
При этом, само подключение корутин заняло меньше дня. Поменял sleep на delay и добавил suspend по вкусу (да, один класс пришлось переписать на Java, но IDEA хорошо сконвертировала).
Потом несложно (надеюсь) будет перейти на асинхронынй HTTP клиент. И тогда «время ответа сервера» тоже не будет требовать «треда на стороне jmeter’а».
С точки зрения «бизнеса» :
1) Можно будет генерировать бОльшую нагрузку с одой нагрузочной машины. Это сильно упрощает написание скриптов и тестирование. Любая схема, когда нужно «запускать нагрузку с N машин, а потом как-то агрегировать логи» сложнее, чем «запустить с одной».
2) Можно будет использовать реалистичные паузы и не упираться в «unable to create native thread».
Как-то так.
Смысл в следующем: JMeter используют для генерации нагрузки обычные потоки.
И очень часто нагрузка должна быть осмысленная. Т.е. не просто нужно молотить непрерывно, а важно делать паузы между запросами, эмулируя действия реального пользователя, который иногда думает между кликами (по 5-10 секунд запросто).
Получается, если мы заходим эмулировать нагрузку от 50’000 условных пользователей, то в обычном JMeter’е нужно 50’000 тредов. И, да, большую часть времени эти потоки будут спать в sleep’ах.
В случае корутин же столько потоков не нужно. Да, «локальное состояние каждого псевдо-потока хранить всё равно нужно». Но вот тредов нужно меньше.
Что я и сделал: впилил корутины в JMeter и на тесте в 100’000 «потоков с паузами по 1сек» он прямо в JMeter UI показывает 97’000 requests/second.
При этом, само подключение корутин заняло меньше дня. Поменял sleep на delay и добавил suspend по вкусу (да, один класс пришлось переписать на Java, но IDEA хорошо сконвертировала).
Потом несложно (надеюсь) будет перейти на асинхронынй HTTP клиент. И тогда «время ответа сервера» тоже не будет требовать «треда на стороне jmeter’а».
С точки зрения «бизнеса» :
1) Можно будет генерировать бОльшую нагрузку с одой нагрузочной машины. Это сильно упрощает написание скриптов и тестирование. Любая схема, когда нужно «запускать нагрузку с N машин, а потом как-то агрегировать логи» сложнее, чем «запустить с одной».
2) Можно будет использовать реалистичные паузы и не упираться в «unable to create native thread».
Как-то так.
👍
VS
Вообще, конечно, пару лет назад казалось, что «внедрить асинхронность в JMeter займёт годы»
А сейчас берёшь Kotlin и всего делов. Прямо огонь.
А сейчас берёшь Kotlin и всего делов. Прямо огонь.
2019 October 21
VS
Оказалось, современные корутины не показывают стектрейс при CancellationException.
Иными словами, невозможно понять «чем хоть примерно» занималась корутина когда её отменяли.
https://stackoverflow.com/questions/58482407/is-there-a-way-to-understand-what-the-coroutine-was-doing-when-it-was-cancelled
Иными словами, невозможно понять «чем хоть примерно» занималась корутина когда её отменяли.
https://stackoverflow.com/questions/58482407/is-there-a-way-to-understand-what-the-coroutine-was-doing-when-it-was-cancelled
Ⓢ
Да, их отлаживать то ещё удовольствие. Хорошо, что есть log.debug() и log.trace() 😊
AN
Оказалось, современные корутины не показывают стектрейс при CancellationException.
Иными словами, невозможно понять «чем хоть примерно» занималась корутина когда её отменяли.
https://stackoverflow.com/questions/58482407/is-there-a-way-to-understand-what-the-coroutine-was-doing-when-it-was-cancelled
Иными словами, невозможно понять «чем хоть примерно» занималась корутина когда её отменяли.
https://stackoverflow.com/questions/58482407/is-there-a-way-to-understand-what-the-coroutine-was-doing-when-it-was-cancelled
Так это cancel - это штатный выход. Не должно быть там трейса.
2019 October 22
SM
Так это cancel - это штатный выход. Не должно быть там трейса.
Не должно быть из каких-то теоретических соображений?
AN
Не должно быть из каких-то теоретических соображений?
Из практических. Генерация трейса - это весьма дорого
SM
Из практических. Генерация трейса - это весьма дорого
Это понятно. Но если теоретическая возможность посмотреть на стек корутины всё таки есть, может можно затащить это в какую-нибудь проперти, чтобы при необходимости у пользователя была всё-таки возможность посмотреть 😀
VS
Из практических. Генерация трейса - это весьма дорого
Хочу заметить, что я прошу про
А эта операция у корутины бывает лишь однажды.
Я понимаю, что тяжело «задним числом» узнать все её supsension точки.
Но можно же в момент «когда мы ей сказали остановиться» заставить эту корутину создать хотя бы один стек. Хотя бы того места, где она проснулась и обнаружила cancellation.
Стоит помнить, что мудрейшие завещали, что «cancellation is cooperative», и корутина реально должна проснуться, чтобы заметить факт своей отмены. И тут в самый раз был бы сбор стектрейса.
Я слоняюсь к тому, что это просто баг.
.cancel()А эта операция у корутины бывает лишь однажды.
Я понимаю, что тяжело «задним числом» узнать все её supsension точки.
Но можно же в момент «когда мы ей сказали остановиться» заставить эту корутину создать хотя бы один стек. Хотя бы того места, где она проснулась и обнаружила cancellation.
Стоит помнить, что мудрейшие завещали, что «cancellation is cooperative», и корутина реально должна проснуться, чтобы заметить факт своей отмены. И тут в самый раз был бы сбор стектрейса.
Я слоняюсь к тому, что это просто баг.
RI
Если корутина просто заснула на delay или yield, то стректрейс будет бесполезным:
thread
dispatcher
onResume
thread
dispatcher
onResume
RI
Только в некоторых случаях типо когда корутина просыпается от запроса к api будет какой-то более-менее полезный трейс
VS
Если корутина просто заснула на delay или yield, то стректрейс будет бесполезным:
thread
dispatcher
onResume
thread
dispatcher
onResume
А почему это так? Бага? Карутина же по-любому должна проснуться и выйти из той функции, которая вызывала delay. Сразу после просыпания у неё стектрейс нормальный и полезный
RI
Корутина это объект, а не функция. Функция там одна
VS
Корутина это объект, а не функция. Функция там одна
И?