Комментарии 21
soapUI/loadUI добавьте пожалуйста в опрос
И последнее, чтобы выжать максимум rps с любой машины, когда неизвестны какие лимиты по соединениям в данной ОСи или общая текущая нагрузка, надежней всего воспользоваться методом проб и ошибок: задать сначала какое-нибудь запредельное значение, например миллион запросов в секунду и далее ждать на каком количестве соединений начнутся ошибки при создании новых. Опыты показали что предельное количество rps обычно чуть поменьше этой цифры.
Т.е. берем эту цифру за начальное значение rps и потом если ошибки повторяются уменьшаем ее на 10-20%.
Есть более простой способ. То что вы описали, это подача нагрузки RPSами, но можно подавать «свободными инстансами или потоками».
Я изначально знаю что мой сервис может обрабатывать 1000 соединений и при этом скорее всего мы достигнем предела scalability.
Беру любой тул, ставлю в нем такое кол-во сокетов и убираю подачу нагрузку по таймеру. Как только соединение освобождается, отсылается новый запрос. В итоге 1000 сокетов будет использоваться настолько быстро, насколько быстро отвечает сервер. Так и определим максимальный RPS, который может отдавать сервер.
С помощью такого метода не нужно делать других ретестов или ждать пока нагрузка дорастет до пары десятков RPS.
А зачем писать свой, когда уже есть Gatling Tool который уже умеет это все из коробки?:)
Gatling Tool тоже монстр +на scala, это конечно не проблема, но порог вхождения есть: dsl, статистика, гуй, интерграция всего со всем… сомневаюсь что это все добавляет быстродействия к netty, который там внутри.
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
Gatling Tool тоже монстр +на scala, это конечно не проблема, но порог вхождения есть: dsl, статистика, гуй, интерграция всего со всем… сомневаюсь что это все добавляет быстродействия к netty, который там внутри.
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Кмк, это изначально лучший путь, т.к. у того проекта уже есть community и куча фич, включая требования.
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
Нет, вообще без таймеров
while(1) { do_request(); }Кмк, это изначально лучший путь, т.к. у того проекта уже есть community и куча фич, включая требования.
в целом я согласен, что когда нужно хотя бы несколько фич из этой кучи, а там уже и community и все остальное, тогда безусловно, но если просто нужно дернуть какой-то метод из своего легаси кода при генерации контента запроса — с этим как, или он это тоже может?
Нет, вообще без таймеров
while(1) { do_request(); }
Но это вроде бы не совсем эмулирует боевую нагрузку: там же каждый раз новые соединения создаются а не старые переиспользуются как у вас.
И сколько максимально rps вам удавалось добиться таким способом? на localhost-е и на удаленный сервер в локальной сетке например?
Но это вроде бы не совсем эмулирует боевую нагрузку: там же каждый раз новые соединения создаются а не старые переиспользуются как у вас.
Вы не поняли. Задача такого теcта «быстро оценить максимальную пропускную способность», чтобы потом уже проводить тесты около неё, эмулируя боевую.
И сколько максимально rps вам удавалось добиться таким способом? на localhost-е и на удаленный сервер в локальной сетке например?
Дело не только в RPSе, дело в протоколе. дело в самой подаче нагрузке даже с обычным таймером. С таймером, у вас запросы идут на сервер с равномерным распределением. Если вы посылаете на сервер 100rps, то каждые 10ms приходит новый запрос. В жизни все иначе, для большинства сервисов подойдет процесс Пуассона, который к слову, почему-то реализован только в twitter iago.
Дело в логике работы и еще много в чем.
Окей, давайте про циферки. В апреле выступал на SQA Days 2013, в докладе показывал 40krps, но с той же Cassadnra были тесты на 95krps.
Пару недель назад делал тесты с asynchbase. 1 нагрузочноая станция, HBase кластер из трех машин, 110krps на отправке 1кб запросов на запись:)
Как только соединение освобождается, отсылается новый запрос. В итоге 1000 сокетов будет использоваться настолько быстро, насколько быстро отвечает сервер. Так и определим максимальный RPS, который может отдавать сервер.
Вы не поняли. Задача такого теcта «быстро оценить максимальную пропускную способность», чтобы потом уже проводить тесты около неё, эмулируя боевую.
А как в этом бесконечном цикле понять что соединение закрылось? Что-то вроде своего пула сокетов, и как только какой-то освобождается нотифицировать все потоки и посылать в этот сокет?
Дело не только в RPSе, дело в протоколе. дело в самой подаче нагрузке даже с обычным таймером. С таймером, у вас запросы идут на сервер с равномерным распределением.
не совсем так, с равномерным распределением мы коннектимся к серверу, а у ж как только коннект асинхронно отработает — посылаем запрос. Это конечно не Пуассоновское распределение, но вся эта асинхронность тоже вносит определенный элемент случайности.
А как в этом бесконечном цикле понять что соединение закрылось? Что-то вроде своего пула сокетов, и как только какой-то освобождается нотифицировать все потоки и посылать в этот сокет?
Не совсем понял вопроса:)
не совсем так, с равномерным распределением мы коннектимся к серверу, а у ж как только коннект асинхронно отработает — посылаем запрос. Это конечно не Пуассоновское распределение, но вся эта асинхронность тоже вносит определенный элемент случайности.
Совсем не понял, как соотносится асинхронность движка с интервалами запросов?
Не совсем понял вопроса:)
Так?
тыща потоков дает на моей машине где то 8 тыщ rps, 4 тысячи потоков => 10K rps, дальнейшее увеличение потоков прироста rps не дает.
Как мне добиться 30K rps которые я на этой же машине получаю с помощью таймера?
Профилируйте, ищите хотспоты и узкие места, расширяйте и передвигайте их. Золотого правила дать, простите, не могу;)
Почитал исходный код. Если вы получаете 30Krps на таком тесте, с переоткрытием сокетов, то можно считать что это предел. Ядро GNU/Linux уже не может чаще переоткрывать сокеты. Граница как раз на 30-35krps.
Посмотрите на утилизацию первых ядер, у вас в tope ядра должны много времени проводить в software irq.
Кстати вы его не закрываете;-)
Посмотрите на утилизацию первых ядер, у вас в tope ядра должны много времени проводить в software irq.
Кстати вы его не закрываете;-)
Почитал исходный код. Если вы получаете 30Krps на таком тесте,
30К может и предел, но получаю я их описанным в посте способом т.е. с использованием таймера, где сокеты тоже переоткрываются естественно. И тогда мне неясно почему Вашим методом я получаю только 10К на той же машине в тех же условиях?
Кстати вы его не закрываете;-)
он там неявно закрывается из br.close(), на всякий случай добавил явно — ничего не поменялось
30К может и предел, но получаю я их описанным в посте способом т.е. с использованием таймера, где сокеты тоже переоткрываются естественно. И тогда мне неясно почему Вашим методом я получаю только 10К на той же машине в тех же условиях?
Ну необходимо смотреть на машинку. Условия априорите не те же. Вы используете синхронные блокирующие сокеты, вместое асинхронных-неблокирующих в netty. Уже разное количество нитей, которые обрабатывают сокеты и много еще нюансов. Давайте перейдем в личку, если хотите продолжить.
Мой основной поинт в закленной отправке запросов был в том, «как быстро оценить максимальную пропускную способность хендлера». Для этого нужно натравить что-то простое вроде ab/wrk или даже тот же yandex-tank без схемы нагрузки и таймеров. и понять максимум. Дальше уже делать новый тест с таймерами и играться около этого уровня пропускной способности.
Коллеги смогли выжать больше 200 000 (да, двести тысяч) RPS, но там было постоянное соединение, операция типа прочитать ключ из кеша. 8 ядер в sys, 8 ядер в usr как на стреляющей машине, так и на сервере-мишени. Стреляли танком.
Ну такие циферки много где актуальны, даже если wrk по nginx пулять можно 500Krps выжать:) lowlatencyweb.wordpress.com/2012/03/20/500000-requestssec-modern-http-servers-are-fast/
Yandex.Tank он на питоне? Тогда сдается мне что это не быстрей простого netty при прочих равных — таже реализация NIO через виртуальную машину (питона в данном случае)
Помнится на Scaladev 2012 был доклад про нагрузочное тестирование на базе Akka 2. Слайды и почти немое кино.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой и быстрый фреймворк для стресс-тестирования приложений