jj
ну естественно утром тебе ответят)
Size: a a a
2021 June 04
ΙΤ
На сами темплейты нет 😂
ΙΤ
Так уж исторически сложилось что не написали доку на темплейты
ΙΤ
Но там есть пример в комментах, из него понятно все
АК
Ммм…. а почему бы не сделать а) случайный пейсинг в диапазоне, и б) поднимать ежесекундно по формуле 900/везуры (15 минут на подъём)? При пейсинге в дипазоне лесенок настолько нет, что их нет даже на поиске максперфа с какого-то момента.
AA
поднимать пейсинг потом это как?, разве можно кодом его менять потом?
VG
Теоретически есть вероятность, что pacing будет всё время выбирать значение побольше
Или поменьше
И это исказит профиль
Это ОЧЕНЬ теоретическая вероятность, но с финктаймом нет и её
Или поменьше
И это исказит профиль
Это ОЧЕНЬ теоретическая вероятность, но с финктаймом нет и её
АК
Нет, поднимать не пейсинг, а вузеров 🙂 Если время поднятия очередной пачки в разы выше пейсинга (и он плавающий) — лесенок нет, всё сглаживается.
AA
обычный рандом в диапазоне + 10% и -10% вроде всегда попадал, разве что на одной версии пц с дробными пейсингами были пляски
АК
Меня такие вероятности тоже напрягают, но нет, на практике такого нет. При расчётном пейсинге в 70 ставишь 60-80 и нет никаких лесенок.
AA
а , ну да если кинуть больше пользаков и размазать их вход то да
АК
Собственно, я задавался вопросом, а не через жопу ли выставляется этот “случайный” пейсинг, т.к. регулярно реальная нагрузка (считаем по опс с приклада) != расчётной, слава богу не в разы, десятые доли максимум.
ВС
Или можно добавить второй таймер на запросы, а не транзакции, тогда графики будут ровными, почти идеальными
ВС
Рандом, считаю, лишь сглаживает. Но не решает проблему
AA
не задавался но расчет сценария ввиде, нашли пейсинг а потом +10% и -10% проблем не вызывал
VG
Думал про этот вариант.
Но когда второго таймера нет - один запрос отрабатывая побыстрее даёт время другому запросу поработать подольше.
А со вторым таймером у нас получается на каждый запрос своё временное окошко
И если он вырывается за него - это сдвинет всё завершение операции
Но когда второго таймера нет - один запрос отрабатывая побыстрее даёт время другому запросу поработать подольше.
А со вторым таймером у нас получается на каждый запрос своё временное окошко
И если он вырывается за него - это сдвинет всё завершение операции
ВС
Сдвинет только если в Transaction Controller стоит галочка Include timers, а по умолчанию она не стоит. И таймеры внутри транзакции на результат не влияют. Но выравнивают RPS
VG
Нее, сдвинется момент завершения итерации
В транзакции это не учтётся, тут вопросов нет
В транзакции это не учтётся, тут вопросов нет
ВС
Из минусов, при изменении списка запросов в транзакции надо будет пересчитатывать таймер на RPS, это да. С одним Random-ом в начале транзакции проще конечно, его не надо пересчитывать