Данила, я разделяю эти понятия, т.к. в них разные цели тестирования.
Мне так проще:) Разделяю т.к. исследования нельзя автоматизировать, а вот регрессию разных релизов можно.
Регрессионное тестирование, это все же отслеживание метрик производительности на большом временном интервале с большим количеством релизов. Он нужен с целью понять тренд производительности.
Если нужно понять насколько изменилась производительность со сменой ядра, версии библиотеки, то это тесты не на регрессию, а на сравнение и исследование.
Кроме того, бывают такие ситуации, когда в попытках исследовать версии библиотек в итоге откатываешься на более древнюю версию ради производительности. Это уже мало на регрессию похоже.
Необходимо просто сделать несколько тестов, сравнить метрики производительности (пропускная способность / время ответа и их распределение / конкуренция). Сравнить системные и софтовые метрики.
В данном случае увеличение памяти лишь отсрочит OutOfMemory. Если очередь наполняется чаще, чем успевает залиться в Oracle, то очередь будет съедать всю память. И Out of Memory в любом случае произойдет, иногда только позже.
На том же яндекс.диске есть jar-ник с суффиксом -mt. Это многопоточная версия заливалки семплов в Oracle. На моих тестах при 10 сессиях удалось выжимать производительность ~30Krps. И вот при использовании такой штуки очередь будет разгребаться быстрее. В её стабильности я не уверен:)
Очень здорово что выложили в open source часть решения, только тут не хватает jar-файла с самим плагином:) И очень жаль что не оформили его ввиде красивого решения из коробки, все же BeanShell Listener пользоваться неудобно.
Кстати всем могу предложить решение аналогичной задачи, но без базы данных Oracle, и с сильно большим количеством метрик производительности.
Общее описание тут, а исходный код и плагин тут.
Да, это очень хороший способ. Кстати если ядро поддерживает systemtap, то через него можно сделать тоже самое. Но иногда приходится и так извиваться:)
Кстати буквально вчера коллега выложил запатченный jemalloc, и послав SIGUSR2 процессу вы сможете увидеть статистику аллокациям к памяти (просто вывод malloc_stats). Просто включить его в LD_PRELOAD и просто послать SIGUSR2;)
Что такое «нагрузка» в вашем понимании? Что-то вроде Load Average?:)
Проблема вся в том, что для пользователя могут начатся тормоза даже при сохранении уровня «нагрузки».
Представьте ситуацию, пользователь открывает свой инвентарь и в базу летит селект и fetch всех строк. И раньше инвентарь был небольшим, и это было можно сделать за одну операцию. Но есть пользователи у которых инвентарь большой, и вы решили сделать select порциями по N строк, используя простой LIMIT. Так вот суть в том, что уровень нагрузки на сервер может остаться тем же, а клиенту необходимо еще все это скомпоновать и результируещее время ответа можеть быть выше чем прежде. На выполнение той же задачи нужно отправить, получить и обработать больше чем раньше.
Если выводить такую информацию в логи, и только изредка поглядывать, то можно пропустить знатные баги для всех пользователей:)
Лучше разграничить все метрики на 2 типа: метрики софта/железа (прикладные/системные) и метрики производительности(время, пропускная способность, времена ответа/отклика, квантили/процентили), и только по последним говорить о производительности. Первый тип имеет только косвенное отношение к производительности:)
Я имел ввиду не метрики и характеристики тестируемого приложения, а сами метрики по которым вы оцениваете производительность. Возможна ситуация когда разработчик решил подправить селект к базе и он стал тяжелым. По метрикам приложения вы этого не заметите, а вот на базе будет творится что-то страшное. Уследить за всеми метриками довольно сложно, хотя если мониторить общесистемные метрики на всех участвоваших машинках можно.
Я имею ввиду именно метрики производительности, время ответа, время отклика, пропускная способность запросов. Как реализована эта часть? Вы просто в CI запускаете, например, 500 ботов и смотрите только на общесистемные метрики, или же всматриваетесь в распределения времен ответов, смотрите как выполнение одних сценариев влияет на другие? Например сценарий инвернтаря хорошо нагрузил базу данных и получение информации об окружающих NPC или игроках замедлилось в N раз.
Боты это только инструмент, и одна из сложных задач это анализ данных от инструмента:) Расскажите, какие метрики выделяете с помощью этих ботов и на какие смотрите? Делаете какие-то регрессионные задачи?:)
Есть еще какие-то сценарии у ботов? Ну например работа с инвентарем, аукцион, или под новый год большая доля пользователей собирается в одной локации ?:)
Тесты запускаете на отдельном стенде, где нет настоящих игроков?:)
30К может и предел, но получаю я их описанным в посте способом т.е. с использованием таймера, где сокеты тоже переоткрываются естественно. И тогда мне неясно почему Вашим методом я получаю только 10К на той же машине в тех же условиях?
Ну необходимо смотреть на машинку. Условия априорите не те же. Вы используете синхронные блокирующие сокеты, вместое асинхронных-неблокирующих в netty. Уже разное количество нитей, которые обрабатывают сокеты и много еще нюансов. Давайте перейдем в личку, если хотите продолжить.
Мой основной поинт в закленной отправке запросов был в том, «как быстро оценить максимальную пропускную способность хендлера». Для этого нужно натравить что-то простое вроде ab/wrk или даже тот же yandex-tank без схемы нагрузки и таймеров. и понять максимум. Дальше уже делать новый тест с таймерами и играться около этого уровня пропускной способности.
Почитал исходный код. Если вы получаете 30Krps на таком тесте, с переоткрытием сокетов, то можно считать что это предел. Ядро GNU/Linux уже не может чаще переоткрывать сокеты. Граница как раз на 30-35krps.
Посмотрите на утилизацию первых ядер, у вас в tope ядра должны много времени проводить в software irq.
А как в этом бесконечном цикле понять что соединение закрылось? Что-то вроде своего пула сокетов, и как только какой-то освобождается нотифицировать все потоки и посылать в этот сокет?
Не совсем понял вопроса:)
не совсем так, с равномерным распределением мы коннектимся к серверу, а у ж как только коннект асинхронно отработает — посылаем запрос. Это конечно не Пуассоновское распределение, но вся эта асинхронность тоже вносит определенный элемент случайности.
Совсем не понял, как соотносится асинхронность движка с интервалами запросов?
Но это вроде бы не совсем эмулирует боевую нагрузку: там же каждый раз новые соединения создаются а не старые переиспользуются как у вас.
Вы не поняли. Задача такого теcта «быстро оценить максимальную пропускную способность», чтобы потом уже проводить тесты около неё, эмулируя боевую.
И сколько максимально rps вам удавалось добиться таким способом? на localhost-е и на удаленный сервер в локальной сетке например?
Дело не только в RPSе, дело в протоколе. дело в самой подаче нагрузке даже с обычным таймером. С таймером, у вас запросы идут на сервер с равномерным распределением. Если вы посылаете на сервер 100rps, то каждые 10ms приходит новый запрос. В жизни все иначе, для большинства сервисов подойдет процесс Пуассона, который к слову, почему-то реализован только в twitter iago.
Дело в логике работы и еще много в чем.
Окей, давайте про циферки. В апреле выступал на SQA Days 2013, в докладе показывал 40krps, но с той же Cassadnra были тесты на 95krps.
Пару недель назад делал тесты с asynchbase. 1 нагрузочноая станция, HBase кластер из трех машин, 110krps на отправке 1кб запросов на запись:)
Там обвязка на питоне. Внутри можно ставить разные движки, основной phantom, он написан на Сях и может подавать нагрузку порядка 200Krps. Можно так же пользоваться ab и jmeter.
Gatling Tool тоже монстр +на scala, это конечно не проблема, но порог вхождения есть: dsl, статистика, гуй, интерграция всего со всем… сомневаюсь что это все добавляет быстродействия к netty, который там внутри.
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Кмк, это изначально лучший путь, т.к. у того проекта уже есть community и куча фич, включая требования.
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
Мне так проще:) Разделяю т.к. исследования нельзя автоматизировать, а вот регрессию разных релизов можно.
Если нужно понять насколько изменилась производительность со сменой ядра, версии библиотеки, то это тесты не на регрессию, а на сравнение и исследование.
Кроме того, бывают такие ситуации, когда в попытках исследовать версии библиотек в итоге откатываешься на более древнюю версию ради производительности. Это уже мало на регрессию похоже.
Необходимо просто сделать несколько тестов, сравнить метрики производительности (пропускная способность / время ответа и их распределение / конкуренция). Сравнить системные и софтовые метрики.
В начале теста yandex-tank заходит по ssh на указанные машины и снимает системные метрики. Есть возможность указания кастомных метрик.
Конфиг мониторинга выглядит примерно так. Для наглядности добавил кастомную метрику количества всех TCP-сокетов на системе.
На том же яндекс.диске есть jar-ник с суффиксом -mt. Это многопоточная версия заливалки семплов в Oracle. На моих тестах при 10 сессиях удалось выжимать производительность ~30Krps. И вот при использовании такой штуки очередь будет разгребаться быстрее. В её стабильности я не уверен:)
Кстати всем могу предложить решение аналогичной задачи, но без базы данных Oracle, и с сильно большим количеством метрик производительности.
Общее описание тут, а исходный код и плагин тут.
Кстати буквально вчера коллега выложил запатченный jemalloc, и послав SIGUSR2 процессу вы сможете увидеть статистику аллокациям к памяти (просто вывод malloc_stats). Просто включить его в LD_PRELOAD и просто послать SIGUSR2;)
Проблема вся в том, что для пользователя могут начатся тормоза даже при сохранении уровня «нагрузки».
Представьте ситуацию, пользователь открывает свой инвентарь и в базу летит селект и fetch всех строк. И раньше инвентарь был небольшим, и это было можно сделать за одну операцию. Но есть пользователи у которых инвентарь большой, и вы решили сделать select порциями по N строк, используя простой LIMIT. Так вот суть в том, что уровень нагрузки на сервер может остаться тем же, а клиенту необходимо еще все это скомпоновать и результируещее время ответа можеть быть выше чем прежде. На выполнение той же задачи нужно отправить, получить и обработать больше чем раньше.
Если выводить такую информацию в логи, и только изредка поглядывать, то можно пропустить знатные баги для всех пользователей:)
Лучше разграничить все метрики на 2 типа: метрики софта/железа (прикладные/системные) и метрики производительности(время, пропускная способность, времена ответа/отклика, квантили/процентили), и только по последним говорить о производительности. Первый тип имеет только косвенное отношение к производительности:)
Я имею ввиду именно метрики производительности, время ответа, время отклика, пропускная способность запросов. Как реализована эта часть? Вы просто в CI запускаете, например, 500 ботов и смотрите только на общесистемные метрики, или же всматриваетесь в распределения времен ответов, смотрите как выполнение одних сценариев влияет на другие? Например сценарий инвернтаря хорошо нагрузил базу данных и получение информации об окружающих NPC или игроках замедлилось в N раз.
Есть еще какие-то сценарии у ботов? Ну например работа с инвентарем, аукцион, или под новый год большая доля пользователей собирается в одной локации ?:)
Тесты запускаете на отдельном стенде, где нет настоящих игроков?:)
Ну необходимо смотреть на машинку. Условия априорите не те же. Вы используете синхронные блокирующие сокеты, вместое асинхронных-неблокирующих в netty. Уже разное количество нитей, которые обрабатывают сокеты и много еще нюансов. Давайте перейдем в личку, если хотите продолжить.
Мой основной поинт в закленной отправке запросов был в том, «как быстро оценить максимальную пропускную способность хендлера». Для этого нужно натравить что-то простое вроде ab/wrk или даже тот же yandex-tank без схемы нагрузки и таймеров. и понять максимум. Дальше уже делать новый тест с таймерами и играться около этого уровня пропускной способности.
Посмотрите на утилизацию первых ядер, у вас в tope ядра должны много времени проводить в software irq.
Кстати вы его не закрываете;-)
Не совсем понял вопроса:)
Совсем не понял, как соотносится асинхронность движка с интервалами запросов?
Вы не поняли. Задача такого теcта «быстро оценить максимальную пропускную способность», чтобы потом уже проводить тесты около неё, эмулируя боевую.
Дело не только в RPSе, дело в протоколе. дело в самой подаче нагрузке даже с обычным таймером. С таймером, у вас запросы идут на сервер с равномерным распределением. Если вы посылаете на сервер 100rps, то каждые 10ms приходит новый запрос. В жизни все иначе, для большинства сервисов подойдет процесс Пуассона, который к слову, почему-то реализован только в twitter iago.
Дело в логике работы и еще много в чем.
Окей, давайте про циферки. В апреле выступал на SQA Days 2013, в докладе показывал 40krps, но с той же Cassadnra были тесты на 95krps.
Пару недель назад делал тесты с asynchbase. 1 нагрузочноая станция, HBase кластер из трех машин, 110krps на отправке 1кб запросов на запись:)
Кмк, это изначально лучший путь, т.к. у того проекта уже есть community и куча фич, включая требования.
Нет, вообще без таймеров
while(1) { do_request(); }