Яндекс-танк добавляет инстансов — этим и противоречите себе — новый instance = другой профиль.
Тогда давайте начинать сразу слать сразу в 400 потоков (одновременно), смотреть что latencety выросло и добавлять ещё…
Вам уже писали, что используете не правильный подход замера, так же писали что колебания доходят до 40% на одном и той же посылке.
По мне правильный подход для оценки решения следующий:
Вы даете постоянную нагрузку на систему в k потоков(синхронные запросы) в заданный промежуток времени и получаете количество успешных и валидных ответов. К этому можно замерять 95 перцентиль. И из полученных показателей обработанных сообщений и времени строить рейтинг.
Дальше по задаче: затраты ресурсов на логику должны больше. Перед стартом обстрелом делаю свой тест железа.
String idString = request.getRequestURI().replace("/tests/","");
writer.write(idString);
И получаю
client_8513_1 |TestGet:=0.10689574209999998 ms Amount := 10000
client_8513_1 |TestRealGet:=2.2555675474 ms Amount := 10000
0.1 мс на работу внутри пустого севлета, и 2.25 мс снаружи.
А теперь задача. Средняя время работы логики
client_8513_1 |UserNew:=0.16407041119402985 ms Amount := 1340
0.16 мс на запрос
Из этого следует. Можно нафиг выкинуть всю логику (сделать только вывод id из request path), которую надо реализовать, а просто меряться языком на котором участник пишет и на сколько легок его http сервер…
По мне в соревнованиях хочется мериться в скорости в том, что ты пишешь, а не в том какой язык + framework, хотя может действительно смысл контеста писать сам сервер, а не логику.
Что за жесть, почему у вас не совпадают профили на двух рейтинговых посылках.
В одном посылке максимальное количество instance 3, в другой 378 — это как понимать? В гарантируете что текущий рейтинг у каждого пользователь построен по одному профилю. Вы гарантируете, что у всех пользователей в каждый такт времени делаете одинаковое количество запросов?
Как проходит валидация ответов на редактирование/обновление? Например, прислали одновременно N запросов на изменение одного id. Произвольный из них считается последним. Как будет проверено, что все запросы отработали корректно?
Тогда давайте начинать сразу слать сразу в 400 потоков (одновременно), смотреть что latencety выросло и добавлять ещё…
Вам уже писали, что используете не правильный подход замера, так же писали что колебания доходят до 40% на одном и той же посылке.
По мне правильный подход для оценки решения следующий:
Вы даете постоянную нагрузку на систему в k потоков(синхронные запросы) в заданный промежуток времени и получаете количество успешных и валидных ответов. К этому можно замерять 95 перцентиль. И из полученных показателей обработанных сообщений и времени строить рейтинг.
Дальше по задаче: затраты ресурсов на логику должны больше. Перед стартом обстрелом делаю свой тест железа.
String idString = request.getRequestURI().replace("/tests/","");
writer.write(idString);
И получаю
client_8513_1 |TestGet:=0.10689574209999998 ms Amount := 10000
client_8513_1 |TestRealGet:=2.2555675474 ms Amount := 10000
0.1 мс на работу внутри пустого севлета, и 2.25 мс снаружи.
А теперь задача. Средняя время работы логики
client_8513_1 |UserNew:=0.16407041119402985 ms Amount := 1340
0.16 мс на запрос
Из этого следует. Можно нафиг выкинуть всю логику (сделать только вывод id из request path), которую надо реализовать, а просто меряться языком на котором участник пишет и на сколько легок его http сервер…
По мне в соревнованиях хочется мериться в скорости в том, что ты пишешь, а не в том какой язык + framework, хотя может действительно смысл контеста писать сам сервер, а не логику.
В одном посылке максимальное количество instance 3, в другой 378 — это как понимать? В гарантируете что текущий рейтинг у каждого пользователь построен по одному профилю. Вы гарантируете, что у всех пользователей в каждый такт времени делаете одинаковое количество запросов?