VG
Ну, а это похоже на то, что нужно?
Size: a a a
2021 March 09
VB
при условии что не важен срок жизни сессии. если важен то следует менять подход вообще полностью, но пытаться реального медленного юзера сделать с помощью долгих таймеров - самый плохой вариант)
Зибель - штука неторопливая, да и процессы занимают время. Так что нам действительно нужно делать медленного юзера.
VB
Ну, а это похоже на то, что нужно?
Вроде да.
VG
как мы взяли с прода стату запихнули её в скрипт, а получили разное количество сессий активных в момент времени?
Значит ещё взяли время входа-выхода пользака и посчитали сколько их было :)
KY
Зибель - штука неторопливая, да и процессы занимают время. Так что нам действительно нужно делать медленного юзера.
нет, зибелю все равно кто будет делать в нем действия 100 тредов или 1000
ВС
Использую вот такие запросы. Отдельно по каждому генератору и суммарный по всем.
Важен фильтр по internal. Метрика считается по meanAT
Важен фильтр по internal. Метрика считается по meanAT
VB
нет, зибелю все равно кто будет делать в нем действия 100 тредов или 1000
Если удастся сделать сотней тредов 1000 активных сессий - да.
KY
Использую вот такие запросы. Отдельно по каждому генератору и суммарный по всем.
Важен фильтр по internal. Метрика считается по meanAT
Важен фильтр по internal. Метрика считается по meanAT
а я так понял что задача как раз в сумме со всех источников
VG
Использую вот такие запросы. Отдельно по каждому генератору и суммарный по всем.
Важен фильтр по internal. Метрика считается по meanAT
Важен фильтр по internal. Метрика считается по meanAT
О, про internal не знал.
Интересно поиграться будет!
Интересно поиграться будет!
VG
А за что он отвечает?
ВС
а я так понял что задача как раз в сумме со всех источников
Это запрос C на картинке
VG
Вроде да.
Попробуй группировку по разным жметрам - так поймёшь, кто фонит выбросами.
Но для этого надо в каждом жметре в backend listner написать уникальное значение (в application, кажется)
Но для этого надо в каждом жметре в backend listner написать уникальное значение (в application, кажется)
KY
Если удастся сделать сотней тредов 1000 активных сессий - да.
бинго, в таком случае зачем делать долгого пользователя намеренно? каждый тред это ресурсы, каждый ресурсы выделяется с определенной максимальной скоростью, твое огромное количество пользователей может не успеть создаваться и инициализироваться, просто потому что их слишком много. такое количестов тебе может быть не нужно, а меньшее количество работало бы лучше
KY
меньше тредов -> меньше необходимых ресурсов ->оптимальнее скрипты
KY
когда у тебя в хипах перекладывается 20 тон оперативы, GC вычищает еще столько же, у тебя просто за счет этого может деградировать потому что работа с памятью не такая мгновенная как кажется
VG
бинго, в таком случае зачем делать долгого пользователя намеренно? каждый тред это ресурсы, каждый ресурсы выделяется с определенной максимальной скоростью, твое огромное количество пользователей может не успеть создаваться и инициализироваться, просто потому что их слишком много. такое количестов тебе может быть не нужно, а меньшее количество работало бы лучше
Потому, что это геморрой, держать 1000 активных сессий из 100 скриптов
KY
Потому, что это геморрой, держать 1000 активных сессий из 100 скриптов
не понял, точно тут слово "скриптов"?
VG
не понял, точно тут слово "скриптов"?
Нее, прав
Тредов
Тредов
KY
Потому, что это геморрой, держать 1000 активных сессий из 100 скриптов
наоборот это оптимальное использование ресурсов)
KY
если можно сделать 1000 сессий меньшими усилиями, зачем делать большими?)