perf test bannerlord performance test что это
Вступление
Ух, надеюсь, что по бета-версии Mount & Blade 2: Bannerlord у меня больше не будет поводов написать статью, так как в этой статье я намерен собрать для вас всю информацию воедино, а также поведать вам о той самой с первого взгляда «прекрасной» оптимизации, а также постараться ответить на некоторые вопросы от фанатов об этой игре.
реклама
Итак, не буду долго затягивать со вступительной частью, давайте же сразу перейдем к тестовому стенду.
Тестовый стенд
Тестирование Mount & Blade 2: Bannerlord проводилось на следующей конфигурации:
реклама
В качестве средств измерения быстродействия применялись утилиты Fraps и MSI Afterburner, а для построения графиков и диаграмм использовался типичный Excel, с этого дня в моих статьях графики будут только от нуля.
Часть первая: полусинтетические тестовые отрезки
Исследование влияния количества ядер и SMT на производительность
Но в моих тестах это просто непозволительно и я тестирую игру вот так (если в режиме окна)
реклама
Это уже классическое 640х480 с 20% рендерингом.
Настройки максимальные, но сглаживание отключил, чтобы ничего в мою видеокарту не уперлось.
Итак, для начала я хотел бы продемонстрировать вам, как 1000 NPC на лошадях могут загрузить разное количество ядер и потоков, ракурс специально выбирался такой,чтобы уловить максимальную загрузку всех ядер, при этом находясь в статике.
реклама
Вам может показаться смешным тестировать игры в таком сверхнизком разрешении экрана, но когда ты обладатель далеко не самой мощной видеокарты, тебе приходится ради своего дела идти даже на такие извращения. Кстати говоря, на поле боя все 16 потоков могут спокойно «загрузиться» на 100%, привет всем полиядерным машинам, настал наш черед.
Итак, методика тестирования использовалась следующая. Я, находясь на лошади, медленно проезжал посреди колонны вдоль, что занимало чуть больше минуты. Для математической точности исследования лошадь двигалась на автомате, а замеры в течение минуты писались программой FRAPS и вносились автоматически в таблицы.
Вот, каких результатов мне удалось достичь после шести «прогонов».
Из графика сразу же становится понятно, что игра очень любит потоки. Лидерство, безусловно, за шестнадцатью потоками, а вот со вторым и третьим местом все не так однозначно, вполне возможно, что конкретно в этой игре 8 потоков будут сильнее 6 ядер, а 12 потоков полноценных восьми ядер. Их FPS слишком похожи, особенно двенадцатипоточник и восьмиядерник идут нос к носу в начале тестового отрезка и даже пересекаются. Но чем ближе к концу тестового отрезка, тем сильнее восьмиядерник приближается к своему «собрату» с SMT. А вот шестиядерник с четырехъядерником с SMT идут нос к носу и лишь под конец тестового отрезка шесть ядер резко вырываются вперед.
Безусловным аутсайдером в «гонке FPS» остается четырехъядерник без SMT. Ему очень повезло удержаться и на первом же тестировании не опуститься ниже 30 кадров.
Но 1% FPS все расставляет на свои места. Чудес не происходит и потоки дают значительную прибавку к плавности лишь в случае с малым количеством ядер.
Но это лишь искусственный тестовый отрезок, который прост в использовании, но не показывает реальную производительность процессоров в этой игре, вы далее это увидите.
Исследование влияния частоты оперативной памяти на производительность.
Далее мы переходим к вопросу с оперативной памятью. В исследовании будет принимать участие память на трех частотах^ 2666MHz, 3000MHz и 3400MHz.
Прошу ознакомиться с представителями более подробно
Тестирование проводится по идентичной методике. Не хочу тратить ваше время на расписывание одной и той же методики, просто перейдем к результатам.
Прирост от разгона оперативной памяти получился явно выше, чем от перехода со «стока» на «XMP». Игра отлично отзывается на рост частоты памяти и уменьшение таймингов.
Но опять же, это все такие игровые ситуации, которые могут продемонстрировать лишь потенциал, а в реальных крупных сражениях начинает все идти совсем не так, как хотелось бы.
Часть вторая: испытание процессоров в «боевых» условиях
Итак, тест заключался в следующем. Я просто играл на каждом соотношении ядер и потоков. Сражения производились в масштабах 500 на 500 NPC с максимальными настройками графики в минимальном разрешении экрана, чтобы избежать упора в видеокарту.
И вот такие результаты у меня получились. Вы будете шокированы также, как был шокирован я.
И нет, это не какой-то бред, а FPS за бой.
Чтобы закончить тест на четырех ядрах, мне пришлось им «в помощь» еще двух подключать, иначе это был бы фриз на веки.
Итак, теперь, я надеюсь, что новые тесты вам пригляделись и все сделали собственные выводы, которыми вы можете поделиться в комментариях, буду рад обсудить релиз игры и ее «оптимизированность» или «убогость», кто как считает.
Вопросы об оптимизации
1. Возмоно ли поиграть в игру на стареньком ноутбуке или на двухъядерном процессоре?
Да, вполне возможно, если у процессора есть SMT или HT. Я поиграл баталию, вполне себе годно. Без SMT играть становится невозможно. Не забываем учитывать кэш и частоту памяти! Также значительно улучшит ситуацию включение вертикальной синхронизации, чтобы лишний раз не давать напрягаться процессору.
2. Сколько оперативной памяти нужно для игры?
Все равно придется иметь минимум 8 гигабайт.
3. Минимальная видеокарта для этой игры?
Radeon HD 7850 и только на 2Gb.
Заключение
Итак, вот и подошел к концу полный предрелизный тест Mount & Blade 2: Bannerlord. Игра не дает простаивать полиядерникам, а на минимальных настройках графики способна обойтись каким-нибудь четырехпоточным процессором. Я считаю, что у TaleWorlds Entertainment должен выйти качественный продукт, который привлечет внимание как старой аудитории, так и наверстает новых фанатов. Расчехляйте свои кошельки, выход игры уже не за горами.
Perf и flamegraphs
Огромную популярность набирает тема повышения производительности операционных систем и поиска узких мест. В этой статье мы расскажем об одном инструменте для поиска этих самых мест на примере работы блочного стека в Linux и одного случая траблшутинга работы хоста.
Пример 1. Тестовый
Ничего не работает
Тестирование в нашем отделе ― это синтетика на продуктовом железе, а позже ― тесты прикладного ПО. К нам на тестирование поступил диск Intel Optane. Ранее о тестировании дисков Optane мы уже писали в нашем блоге.
Диск был установлен в сервер стандартной комплектации, собранный относительно давно под один из облачных проектов.
Во время тестирования диск показал себя не лучшим образом: при тесте с глубиной очереди в 1 запрос в 1 поток, блоками в 4Кбайта около
70Kiops. А это значит, что время ожидания ответа огромно: примерно 13 микросекунд на запрос!
Странно, ведь спецификация обещает “Latency ― Read 10 µs”, а у нас получилось на 30% больше, разница довольно существенная. Диск переставили в другую платформу, более «свежей» сборки, используемую в другом проекте.
Почему оно работает?
9 микросекунд на запрос.
И тут самое время сравнить настройки достать из широких штанин perf. Ведь нам интересно, почему так? При помощи perf можно:
Суть в том, что perf может собрать весь стэк трейс запущенной программы. Естественно, запущенный perf будет вносить задержку в работу всей системы. Но у нас есть флаг -F #, где # ― частота сэмплирования, измеряемая в Гц.
Тут важно понимать, что чем выше частота сэмплирования, тем больше шансов поймать вызов какой-то конкретной функции, но тем больше тормозов работа профайлера вносит в систему. Чем меньше частота, тем больше шансов, что часть стека мы не увидим.
При выборе частоты нужно руководствоваться здравым смыслом и одной хитростью — стараться не выставлять четную частоту, чтобы не попасть в ситуацию, когда в сэмплы попадет какая-то работа, выполняющаяся по таймеру с этой частотой.
Ещё один момент, который поначалу вводит в заблуждение ― ПО должно быть собрано с флагом -fno-omit-frame-pointer, если это, конечно, возможно. Иначе в трейсе вместо названий функций мы увидим сплошные значения unknown. Для некоторого ПО отладочные символы идут отдельным пакетом, например, someutil-dbg. Рекомендуется установить их перед запуском perf.
Нами были выполнены следующие действия:
Посмотреть полученный результат можно командой:
Опция -g fractal нужна для того, чтобы проценты, отражающие количество сэмплов с этой функцией и показываемые perf, были относительны вызывающей функции, количество вызовов которой берется за 100%.
Ближе к концу длинного стека вызовов fio на платформе «свежей сборки» мы увидим:
А на платформе “старой сборки”:
Отлично! Но хочется красивых флеймграфов.
Построение флеймграфов
Чтобы было красиво, есть два инструмента:
Скачиваем result и отправляем его через пайпы в svg:
Открываем в браузере и наслаждаемся кликабельной картинкой.
Можно использовать другой способ:
Что мы видим в итоге?
Хороший fio проводит много времени в поллинге:
А плохой fio проводит время где угодно, но только не в поллинге:
С первого взгляда кажется, что на старом хосте не работает поллинг, но везде стоит ядро 4.15 одной сборки и поллинг по умолчанию включен на NVMe-дисках. Проверить, включен ли поллинг, можно в sysfs:
Во время тестов используются вызовы preadv2 с флагом RWF_HIPRI ― необходимое условие для работы поллинга. И, если внимательно изучить флеймграф (или предыдущий скриншот из вывода perf report), то его можно найти, но он занимает совсем незначительный промежуток времени.
Второе, что видно ― это отличающийся стек вызовов у функции submit_bio() и отсутствие вызовов io_schedule(). Посмотрим поближе на разницу внутри submit_bio().
Медленная платформа «старой сборки»:
Быстрая платформа «свежей»:
Похоже, что на медленной платформе запрос проходит долгий путь до устройства, заодно попадая в планировщик kyber. О планировщиках ввода/вывода подробнее можно прочитать в нашей статье.
Как только kyber был выключен, тот же тест fio показал среднее время ожидания около 10 микросекунд, прямо как заявлено в спецификации. Отлично!
Но откуда разница еще в одну микросекунду?
А если чуть глубже?
Как уже было сказано, perf позволяет собирать статистику с аппаратных счетчиков. Попробуем посмотреть количество кэш-промахов и инструкций на цикл:
Из результатов видно, что быстрая платформа выполняет больше инструкций на цикл CPU и имеет меньший процент кэш-промахов при выполнении. Вдаваться в детали работы разных аппаратных платформ в рамках этой статьи мы, конечно, не будем.
Пример 2. Продуктовый
Что-то идет не так
В работе распределенной системы хранения данных был замечен рост нагрузки на CPU на одном из хостов при росте входящего трафика. Хосты равноправные, равнозначные и имеют идентичные аппаратное и программное обеспечение.
Рассмотрим как выглядит нагрузка на CPU:
Проблема возникла в 09:23:46 и мы видим, что процесс работал в пространстве ядра исключительно в течении всей секунды. Посмотрим на то, что происходило внутри.
Почему так медленно?
В данном случае мы сняли сэмплы со всей системы:
Опция -a нужно здесь для того, чтобы perf снимал трейсы со всех CPU.
Откроем perf.results при помощи flamescope, чтобы отследить момент повышенной нагрузки на CPU.
Перед нами «тепловая карта», обе оси (X и Y) которой представляют собой время.
По оси X пространство разбито на секунды, а по оси Y ― на отрезки по 20 миллисекунд в пределах секунд X. Время идет снизу вверх и слева направо. Наиболее яркие квадраты имеют наибольшее количество сэмплов. То есть, CPU в это время работал активнее всего.
Собственно, нас интересует красное пятно посередине. Выделяем его мышкой, кликаем и смотрим, что оно скрывает:
В целом, уже видно, что проблема заключается в медленной работе tcp_recvmsg и skb_copy_datagram_iovec в ней.
Для наглядности сравним с сэмплами другого хоста, на котором тот же объем входящего трафика не вызывает проблем:
Исходя из того, что мы имеем одинаковое количество входящего трафика, идентичные платформы, которые работают уже длительное время без остановки, можно предположить, что проблемы возникли на стороне железа. Функция skb_copy_datagram_iovec копирует данные из структуры ядра в структуру в пространстве пользователя, чтобы передать дальше приложению. Вероятно, имеются проблемы с памятью хоста. При этом, в логах ошибок нет.
Перезапускаем платформу. При загрузке BIOS видим сообщение о битой планке памяти. Замена, хост стартует и проблема с перегруженным CPU больше не воспроизводится.
Постскриптум
Производительность системы с perf
Вообще говоря, на загруженной системе запуск perf может внести задержку в обработку запросов. Размер этих задержек зависит в том числе и от нагрузки на сервер.
Попробуем найти эту задержку:
Разница не сильно заметна, всего около
Посмотрим, что будет, если увеличить нагрузку:
Здесь разница уже становится заметна. Можно сказать, что система замедлилась менее чем на 1%, но по существу потеря около 7Kiops на высоконагруженной системе может привести к проблемам.
Понятно, что данный пример синтетический, тем не менее он весьма показательный.
Попробуем запустить еще один синтетический тест, который вычисляет простые числа ― sysbench:
Здесь видно, что даже минимальное время обработки увеличилось на 270 микросекунд.
Вместо заключения
Perf ― очень мощный инструмент для анализа производительности и отладки работы системы. Однако, как и с любым другим инструментом, нужно держать себя в руках и помнить, что любая нагруженная система под пристальным наблюдением работает хуже.
Perf test bannerlord performance test что это
Mount & Blade II: Bannerlord
We all have different hardware as well as demands, therefore writing perfect settings for one or few configurations will help almost no one. Therefore there came an idea to me that explaining how various settings work should help you configure your game to however you’d like it to run.
Aspects to consider before setting up Bannerlord:
1. Do you focus on single or multi player game?
Multiplayer is always significantly more demanding than singleplayer, therefore if you plan on playing both I recommend testing results in multiplayer. It is very possible that your PC might run SP smoothly on high, but struggle with stable frame rates on medium in MP.
2. Monitor refresh rate and expectations.
Do you aim at 30, 60, or 144 FPS? When playing single player, the amount of FPS will not matter as much as the player’s reaction as well as intelligence (at least I hope so) will always surpass bots. Therefore choosing stable 30 FPS and more beautiful graphic settings might be more preferable to some than lower quality but smoother image. This is very subjective. Nonetheless, for multiplayer I strongly recommend aiming at 60 FPS or more as the difference might be a matter of killing your enemy or losing to him as with FPS around 30 will give you inferior reaction to what is happening. Giving up graphical eye candy for more smooth image should be your preference. 144 FPS should be aim only if you have high refresh-rate display and powerful hardware to support it.
3. General performance of your system.
Be realistic, how do you suspect the game will run on your hardware? You will not get decent results the first time, so start at some likely to be satisfying results the first time and then either lower or improve settings depending how the game works for you.
The game’s performance depends on: CPU, GPU, RAM and drive. I will assume that you have at least 16 GB of RAM, because if you do not, then you really should upgrade it. Although the game’s store page recommends only 8 GB RAM, the game actually requires 16 GB RAM! 8 GB might not be sufficient and in consequence the game is likely to stutter. The speed of RAM should not affect performance in any significant way, therefore this guide will not mention it further. The guide will focus on the CPU, GPU and drive dependency.
Keeping in mind all of the above, let’s begin.
The below settings should help you change settings depending how CPU or GPU limited your PC is. Next to each setting I put in brackets the device it is dependent. You can ignore «drive» requirements if you have SSD, however, if you still use HDD, then keep those on low.
Video:
Screen Resolution (GPU): Preferably use native of your monitor, only lower if otherwise game is unplayable. Lowering will result in extremely blurry image (unless you still use CRT monitor).
Resolution Scale (GPU): Same as screen resolution, but lowers only 3D resolution without 2D menus.
V-Sync (GPU): Disable unless you experience screen tearing, drawback of V-Sync is that you might experience input lag, therefore it’s better to always leave it off.
Performance:
Estimated GPU Memory Usage: Watch that it never goes beyond your GPU’s capacity when changing any settings!
Это нормально!
The programmer’s worst friend
Что такое перформанс-тестирование
Запись техническая, для порядка, уточнений и ссылания на первоисточники.
Тестирование продуктивности — вот самый точный перевод термина «performance testing».
Но чаще всего используется словосочетание «тестирование производительности«.
А еще чаще мы говорим «перформанс тестинг», чтобы не упариться с переводом.
Непорядок мирового порядка заключается в том, что под словом «перформанс» подразумевается очень много всякого. Например, выступление артистов на сцене — тоже перформанс. Но мы тут далеки от необходимости кого-то в чем-то убеждать.
Большинство уверено, что в «перформансе» речь идет только о максимальных нагрузках, и в чем-то право. Вообще, мнения о том, что подразумевает «перформанс-тестинг», слегка очень сильно расходятся. Этому есть здравое, нижележащее объяснение.
Перформанс-тестированию можно подвергнуть любое приложение или изделие (например, изделие №2), но здесь и далее подразумевается только тестирование веб-ориентированных приложений.
Проверка продуктивности сайта
в принципе подразумевает следующее:
Критерии продуктивности
исследуемого приложения определяются как часть общих требований задолго до того, как это самое приложение появится в сети.
Критерии продуктивности должны быть:
Пример критериев
Делая вид, что основываются на этой информации, веб-строители выбирают подходящие инструменты и программное обеспечение. Например, мы верим в то, что система управления базами данных MySQL выдерживает, не кашляя, 200 одновременных запросов. Точнее, принимает и ставит сукиных детей в очередь. Значит, «Для обеспечения 150 одновременным запросов на разрабатываемом приложении мы выбираем MySQL!» говорят веб-строители, а потом оказывается, что надо было сразу выбирать Berkeley, но «Боржоми» уже закончилось…
Иногда разработчики ничего особо не выбирают, а пользуются тем, что есть и чем они умеют управлять…
Тестировщиков проблема выбора веб-строителей не волнует. Тестировщиков волнует проверка продуктивности этого творения.
Что следует проверять
при перформанс-тестировании, уже придумано до и для нас:
Время отклика
Максимально допустимая нагрузка
Максимально выдерживаемая нагрузка
Время отклика
Среднее время наработки на отказ
Настройка продуктивности
Инструменты для тестирования продуктивности
Бесплатные
Платные
Если много свободного времени
Подготовка, в виде формирования требований к данному виду тестирования, включая нагрузочную модель, является исключительно важным этапом в практике тестирования производительности, так как некорректная нагрузочная модель может привести к результатам не правильно характеризующим поведение системы и сделать затруднительным принятие решений по улучшению производительности Приложения.
Пожалуйста, разубедите меня в том, что за умение проводить перформанс-тестинг платят больше, нежели за мануальное и автоматизированное тестирование.
Ваша оценка:
Поделиться ссылкой:
Понравилось это:
Похожее
комментариев 17
прекрасная статья. и дабы ее еще улучшить:
«Время отклика» — вот это описание встречается в п.1 и п.4
Из текста….
«………..
В тысячный раз увеличивается нагрузка на сервер до тех пор, пока все “узкие места” не объявлены “выявленными и ликвидированными”. Или “выявленными, но признанными недопустимыми”.
Hello all! I like this forum, i found multifarious gripping people on this forum.
Pronounced Community, consideration all!
This is not a forum.
This is a blog, ponial.
TestComplete — надо выбросить. На уровне протокола не поддерживает. Concurrent VUs не создает. И вообще это functional test automation tool.
В бесплатные добавить QEngine.
В платные добавить NeoLoad.
Последний по юзабилити заткнет за пояс все остальные, вместе взятые, и стоит в 10 раз дешевле LoadRunner.
Senior Automaion Developer получает процентов на 20 больше тестера (Senior QA Analyst). Однако, и ручной тестинг не является его основной обязанностью.
Sr. Load/Performance Testing Engineer получает процентов на 10 больше чем Sr. Automation Developer. Потому как развелось немеряно «Record/Playback» automation developers.
По крайней мере, у нас в Канаде.
Круто.
Уточнил в записи.
Хорошая статья, Алексей.
Добавлю, с Вашего позволения.
Performance Testing — собирательное название. Относительно недавно пришло на замену «чистому» определению Load Testing.
И сейчас часто употребляется как Load/Performance Testing.
Подразделы можно выделить такие:
Performance/Regression Testing — снимаем характеристики, и при последующих билдах/патчах сраниваем новые со старыми
Scalability Testing — ищем performance threshold, докуда (No. of concurrent connections) infrastructure (или только application server) может выдерживать нагрузку.
Stress Testing — даем заведомо превышающую норму нагрузку. Это может быть слишком много юзеров, или слишком часто/быстро посылаем запросы. В результате, сервер часть запросов теряет, на часть отвечает невпопад… А тестер радостно потирает руки и пишет баг-репорты.
Endurance Testing — заставляем работать долго, очень долго, пока не вылезут ляпы ресурс-менеджемента. Memory Leakage (не всю память программа освобождает), например. Или сокеты открывали, но не закрывали. Или хэндлеры создавали, но не освобождали. А может банально пожрать все место на диске или в базе данных.
Другие реальные задачи для Performance Testing — поблочное тестирование элементов инфраструктуры, с целью выявления «узких» мест (bottlenecks). Firewall, Router, DB, etc.
PS. Все понятия изначально усваивал на английском, на русском звучит непривычно, честно говоря.
Еще одна хорошая статья:
Я в следующем году тоже открою подраздел лоад тестинга в своем блоге
automationbeyond.wordpress.com
На самом деле тут описывается не только Перформанс в его чистом виде но и Стресс Тестинг (2. Максимально допустимая нагрузка). Эти 2 понятия очень часто путают многие тестеры, но различить их довольно таки лего. Перформанс — это вид тестирования при котором проверяю в основном скорость работы приложения на 1 запрос. Стресс Тестинг — это то как проложение вебед себя при больших нагрузках. Алексей название этой рубрики не совсем подходит к ее описанию. Перформанс часто используется вместе со стресс тестингом но это 2 разные вещи. Да и самое важное «Уточнение: лоад-тестинг является частью перформанс-тестинга.» — это абсолютно не так. Лоад-тестинг также становится Стресс Тестингом в случае когда проверяются пиковые мощности (как описанно во 2-м пунтке).
Среднее время безотказной работы — это не совсем правильный перевод.
Mean time to failure — это Среднее время наработки на отказ в соответствии с ГОСТ 27.002
Хороший пост! По делу и без «воды». Только не понял одну вещь: почему «Иногда вместо “по-дурацки” говорят “логарифмически”.»? По-моему, логарифмически — это даже лучше чем линейно. Вот экспоненциально — это «по-дурацки» 🙂 Логарифм вроде функция хорошая: http://ru.wikipedia.org/wiki/Логарифмическая_функция
Я ёрничаю по-поводу одного недоразумения, который произошел при обсуждении результатов подобного теста.
Девелопер не понял, что ему сказал мой коллега, и очень обиделся 🙂