AR
Перефразирую. 1—3 секунды на опрос агентов + время когда данные долетят до телеграфа, а потом ему надо будет ещё выгрузить в инфлюкс
Size: a a a
2020 March 29
A
ну на самом деле я на 100% не уверен, но должно быть так, да
не уверен потому что не вижу сдвига по времени в настройках, щас гляну какие реально данные уходят
A
Перефразирую. 1—3 секунды на опрос агентов + время когда данные долетят до телеграфа, а потом ему надо будет ещё выгрузить в инфлюкс
а там еще отдельно батчинг настраивается и тп, от них зависит еще когда данные реально уйдут в базу
AR
Ну все равно разброс будет 1—3 секунды а не 2)
A
время метрик - да, но на большой выборке оно нивелируются
AR
Кхм, теперь стало интересно стало. Теперь нужно постоянно держать в голове что ответы могут прилетит в агент не сразу. Что бы относить с JMeter данными
AR
Спасибо.
A
не уверен потому что не вижу сдвига по времени в настройках, щас гляну какие реально данные уходят
так и не нашел сдвиг, но да, он берет время метрики
A
видимо его нет, так что если время на агентах будет +- пару секунд\минут - будут расхождения
A
надеюсь меня поправят и я ошибаюсь
VS
Слушайте. Раз главная проблема JMeter’а (ctrl+z) решена, можно и над более простыми подумать.
А сколько памяти у вас потребляет JMeter?
А сколько памяти у вас потребляет JMeter?
Анонимный опрос
12%
-Xmx не настраиваю, норм работает
0%
-Xmx2g хватает
27%
-Xmx4g и норм
19%
-Xmx8g иначе падает
12%
-Xmx16g в самый раз
15%
Иногда разносим по нескольким машинам, т.к. на одной не хватает
15%
Всегда запускаем с нескольких машин
RY
Слушайте. Раз главная проблема JMeter’а (ctrl+z) решена, можно и над более простыми подумать.
А сколько памяти у вас потребляет JMeter?
А сколько памяти у вас потребляет JMeter?
Анонимный опрос
12%
-Xmx не настраиваю, норм работает
0%
-Xmx2g хватает
27%
-Xmx4g и норм
19%
-Xmx8g иначе падает
12%
-Xmx16g в самый раз
15%
Иногда разносим по нескольким машинам, т.к. на одной не хватает
15%
Всегда запускаем с нескольких машин
Очень сильно зависит от того, что запускать. Если запускать много Java Sampler'ов с использованием Spring'овых бинов, то на 16 потоков легко уйдет 1.6 ГБ
VS
Я к чему. Вот я сейчас сделал простой тест: 10 transaction controller’ов, внутри один flow control action и один constant timer.
Зарядил на 100’000 потоков, и оно упало по памяти, дошло где-то до 40’000 потоков и 2ГБ закончились :(
Хотя, вообще тривиальный тест же, но расход получился ~50КБ на поток
Зарядил на 100’000 потоков, и оно упало по памяти, дошло где-то до 40’000 потоков и 2ГБ закончились :(
Хотя, вообще тривиальный тест же, но расход получился ~50КБ на поток
ВС
Инструмент потребляет столько памяти сколько будет разрешено выделить. Мониторить стал лишь недавно. C помощью telegraf: procstat и jolokia. И с помощью JFR для Java 8: https://github.com/polarnik/Apache.JMeter.Benchmark.NG/blob/master/pom.xml#L891
Мониторить - непростая задача, сама по себе
Мониторить - непростая задача, сама по себе
VS
Ну, а ты знаешь почему тамполучается по 50КБ на поток?
Оно для каждого потока весь testplan клонирует.
Речь не про то, что там запросы-ответы по мегабайту. А про то, что сам тестплан клонируется, хотя на ходу он менятья физически не может :-/
Оно для каждого потока весь testplan клонирует.
Речь не про то, что там запросы-ответы по мегабайту. А про то, что сам тестплан клонируется, хотя на ходу он менятья физически не может :-/
ВС
Я к чему. Вот я сейчас сделал простой тест: 10 transaction controller’ов, внутри один flow control action и один constant timer.
Зарядил на 100’000 потоков, и оно упало по памяти, дошло где-то до 40’000 потоков и 2ГБ закончились :(
Хотя, вообще тривиальный тест же, но расход получился ~50КБ на поток
Зарядил на 100’000 потоков, и оно упало по памяти, дошло где-то до 40’000 потоков и 2ГБ закончились :(
Хотя, вообще тривиальный тест же, но расход получился ~50КБ на поток
Ты описываешь хороший граничный случай. И рассказывал, что планируешь сделать пул потоков для обработки задач, и не копировать jmx в каждый поток. Не знаю, чем могу помочь, но буду рад помочь
Вот об этом речь
https://github.com/apache/jmeter/pull/540
?
Вот об этом речь
https://github.com/apache/jmeter/pull/540
?
VS
Ну, как бы да. После того фикса в количество потоков оно больше не упирается.
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
ВС
Ну, как бы да. После того фикса в количество потоков оно больше не упирается.
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Есть проблема с памятью и потоками. При ожидании ответов. При тестах JMS, AMQP, ... асинхронное что-то памяти не хватает почти сразу.
Придумал, как тут вывернуться, и сделать так, чтобы количество потоков было фиксированным. Но если сделать так, что при паузах потоки не будут тратиться, то будет здорово. Асинхронное тестирование будет расти, думаю
Придумал, как тут вывернуться, и сделать так, чтобы количество потоков было фиксированным. Но если сделать так, что при паузах потоки не будут тратиться, то будет здорово. Асинхронное тестирование будет расти, думаю
ВС
Ну, как бы да. После того фикса в количество потоков оно больше не упирается.
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Пример хороший. У нас на работе проекты большие, по пол мегабайта скрипты. Не по 50 КБайт. Там некопирование в каждый поток будет очень важно
ВС
И мы зная, что копирование есть, теперь стараемся не раздувать тесты, не комментировать там блоки - а сразу удалять всё лишнее и отладочное