Мне нравится идея смотреть гугл аналитику туже по кол-ву уникальных пользователей, и ориентироваться на дельту в росте пользователей за час

Не соглашусь) , тогда логины нужно добавить в основной сценарий нагрузки. Смысл в том что не нужно оценивать производительность на ramp up-е, это время нужно для инициализации и, например, логина , если мы не собираемся его грузить.

Сценарии "реального дня системы" - обычно длительная утопия . Нужно делать пиковый час. Если в этом пиковом часу пользователи логинятся - добавить это в профиль. Для ramp up главное не завалить систему или генераторы нагрузки до основного сценария стабильной подачи нагрузки

Разгон рассчитывается исходя из:

1) что выдерживает система. Многие системы выдают проблемы при быстром разгоне, и эти проблемы могут сказаться на дальнейшей работе. Дедлоки там и тд.

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

3) разгон должен учитывать длительность шага нагрузки (pacing).
Почему это важно?
Предположим, каждый виртуальный пользователь выполняет по операции раз в 5 минут.
Если вы разгоните всех пользователей за минуту, то у вас нагрузка на систему будет волнами:
- Первая минута: все пользаки отработали
- со второй по четвёртую минуты: нагрузки нет вовсе
- пятая минута: все пол заки отработали опять.


В общем, я обычно делаю разгон минут 15. Если системе тяжко - можно и до получаса увеличить.

Максим примерно про такое же выше сказал.

Спасибо всем большое ) в качестсве продукта идет приложение для мобилок , то есть соответсвенно ожидается что люди будут пользоваться им в течении дня без каких то вспышек условно все зашли с утра, я думаю 10-15 минут прирост будет достатосчным для сбора аналитики?

Добрый день! При запуске простого сценария (вход-выход на сайт) jmeter грузить на 50% только 1 ядро ЦПУ из 16. Подскажите пожалуйста как настроить равномерное распределение нагрузки на все ядра ЦПУ?

1. сколько потоков в тред группе жметра?
2. а зачем вы хотите это сделать?

2а потока. Это отладочный тест, чтоб потом не отвлекаться на настройки.

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

он не будет использовать больше 2х ядер. а скорее даже больше 1 т.к пока ждет ответ будет отправлять запрос другим тредом. Если поставите больше потоков - оно само выровняет как ему нужно. Единственное что нужно поправить - размеры лимитов в .bat\.sh для хипа и тп

Спасибо!

Он же вроде по вебсокетному протоколу идёт? Если да, то любая тулза которая с вебсокетами работает. Жиметр с плагином, или гатлинг, например. Но кмк с большими шансами все что не голый вебсокет - некоторая боль в любом случае.

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

Я с сокет ио не работала, у меня был sockjs +stomp. С гатлингом одна сложность была - хартбиты, мессадж раз в неск секунд, и он плохо стыковался с основным сценарием. Если у socket io чего-то такого нет, то и больших проблем вообще не должно быть, просто написать обертку чтобы мессаджи удобно конструировать было.

С gatling для websocket работал. Там на scala сценарии. У меня было 2 транзакции данные генерировал с помощью feeder.

когда GatlingDSL назвали скалой

тоже Gatling используем для этого

Там еще кроме dsl scala поддерживается

Нну, в простых случаях там от скалы ничего почти не надо)

Да ну я писал функцию генерации id для транзакций.