Компания
545,23
рейтинг
25 августа 2014 в 13:15

Разработка → Нагрузочное тестирование Skyforge. Год спустя

Прошло уже больше года после публикации статей, посвященных нагрузочному тестированию Skyforge — новой MMORPG от студии Allods Team. С тех пор изменилось многое: дизайн Хабра, Ubuntu обновилась до 14.04.1 LTS, вышла Java 8, а главное — изменилась стадия развития проекта. Состоялось первое закрытое тестирование на внешних пользователях, а скоро будет и стресс-тест – приглашение максимально возможного числа «живых пользователей» на сервера в рамках ЗБТ или ОБТ. Но не буду отнимать работу у нашей команды маркетинга, расскажу лучше о том, что у нас нового в нагрузочном тестировании, что мы переосмыслили, и что из этого может быть полезно широкой общественности.



Краткое содержание предыдущих частей

  • Skyforge — это MMORPG, действие которого происходит в мире sci-fantasy. Мир в игре будет единым для всех территорий. То есть все игроки России и других стран бывшего СССР смогут вместе выполнять задания, спасать мир и становиться богами. Не будет никакого деления по серверам.
  • Сервер Skyforge написан на Java, архитектура очень подробно описана в соответствующем посте randll.
  • Базы данных — PostgreSQL + распределенные транзакции.
  • Бот — программа, написанная на C++ и имитирующая действия реального игрока. Боты работают по тому же протоколу, что и честный игровой клиент, используют тот же набор команд, и, в целом, с точки зрения сервера слабо отличаются от обычного клиента.
  • Нагрузочное тестирование — совокупность мероприятий, направленных на получение информации о том, способен ли сервер держать положенную нагрузку. Нагрузочные тесты разного характера мы запускаем несколько раз в день. Средний тест идет 40 минут, при этом чистое время теста находится в интервале от 60 до 80 минут.

Больше нагрузочных тестов

Достаточно продолжительное время «клиентские» нагрузочные тесты оставались единственными нагрузочными тестами, которые мы проводили. Но шло время, росли амбиции, менялись потребности и появились задачи требовавшие протестировать нагрузку бóльшую, чем мы могли дать с использованием клиентских ботов. Ограничение было вызвано в первую очередь тем, что клиентские боты занимались очень большим количеством «сторонних» вещей — принимали решения, честно проверяли какие-то условия, играли, в конце концов. Так начали появляться серверные боты, написанные на Java, лишенные всякой логики и просто дающие жару. Сейчас у нас есть три типа таких «ботов»:
  • датабазные — посылают вслепую датабазные операции, используя в качестве исходного профиля профиль реальных игроков с закрытых тестов, и случайные данные;
  • боты для чата — делают то же самое, что и датабазные, только для сервисов чата;
  • генераторы статистики — идея ровно такая же, что и в двух предыдущих случаях, но для подсистемы статистики.

Данные тесты показали себя очень хорошо именно как нагрузочные, большего от них и не ждали. Они не способны найти ошибки, лежащие дальше простого «не работает». Зато отличаются очень хорошей повторяемостью результата, намного дешевле в разработке и, как следствие, поддержке. Если говорить об экономии еще и в железках, то выходит как-то так:
  • для тестирования 10к CCU клиентскими ботами нам в сумме нужно 7 (объекты нагрузки) + 10 (боты) = 17 серверов;
  • для тестирования базы данных 50к CCU серверными: 4 + 2 = 6 серверов;
  • 100к CCU чатика: 4 + 2 = 6 серверов;
  • 100к CCU системы статистики: 2 + 1 = 3 сервера.

Вызвано это в первую очередь тем, что чем дальше мы от боевой конфигурации, тем больше мы можем себе позволить. Например, в тесте системы статистики нет в принципе ни одной запчасти, связанной с самой игрой, только сами приложения, обрабатывающие данные. В тестах чатика или базы данных мы сознательно не нагружаем игровую механику, держа игровой реалм в минимальной запускаемой конфигурации, и только объект нагрузки — в полностью боевом режиме. Также стоит отметить, что чем меньше подсистем участвует в тесте, тем выше стабильность теста.

Клиентские боты

Но как бы прекрасны ни были боты серверные, от клиентских ботов отказываться мы не намерены. Потому что пользы от них существенно больше, а профиль нагрузки максимально приближен к реальному. Поэтому за минувший год они также были значительно улучшены. Теперь они почти абсолютно честно могут проходить значительную часть контента игры. При этом поддержка требуется в минимальном количестве. Выглядит это как-то так: бот появляется на карте, смотрит в свой квест-трекер, видит там указание бежать в точку А и бежит. Благодаря тому, что бот обучен взаимодействовать с окружающим миром, в точке А он последовательно попробует поговорить с кем-нибудь, повзаимодействовать с чем-нибудь или убить всех агрессоров. Почти как в той байке: может ли оно меня съесть? А я его? А могу ли с этим совокупиться? А оно со мной? :)

Также оптимизации самого клиента игры не прошли стороной и наших ботов, так у них значительно снизилось потребление памяти. И теперь мы можем с одной физической машины запускать в два раза больше ботов — 2к вместо 1к.

Клиентские тесты мы сейчас проводим по следующей схеме: все проходят старт игры (самый важный момент для нас с точки зрения нагрузки), все как-то играют (профиль игроков, участвующих в разных активностях взят из головы), все играют на определенной карте. Это позволяет нам находить плохие, с точки зрения нагрузки, карты и оперативно вмешиваться в процесс их создания. Смотреть, какой профиль нагрузки у нас в спокойное время, и быть уверенными, что у нас всё хорошо со стартом игры.



Без этих инструментов нагрузочные тесты были бы в 10 раз более унылые

Пожалуй, это самая полезная часть статьи. При проведении нагрузочных тестов мало знать, держит сервер нагрузку или нет. Самое важное — это возможность быстро понять, что именно идет не так. Здесь неоценимый вклад вносит Java Mission Control и его фича — Flight Recorder. К сожалению, эта опция на боевых серверах достаточно дорогая ($), поэтому мы пользуемся ей только в тестах. Выглядит это как-то так:

-XX:+UnlockCommercialFeatures # Включение поддержки JMC
-XX:+FlightRecorder # Включение режима отложенной записи профиля
-XX:StartFlightRecording=name=skyforge,filename=skyforge.jfr,delay=40m,duration=10m,settings=jmc.jfc


Подробнее можно почитать на сайте Oracle.

Далее этот дамп можно открыть с помощью JMC. В дампе будет представлена вся нужная информация: статистика аллокаций, кто кушал процессорное время, вклад процесса в общий cpu load сервера и многое другое. JMC — это хорошо, но так как на боевых серверах мы его позволить себе не можем, то используем дедовский метод — логи GC, из которых вытаскиваем следующую информацию: сколько времени мы провели за минуту в gc, суммарный application stop time за этот же период, какие объекты были до FullGC, какие — после:

-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintPromotionFailure -Xloggc:memory/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=memory/heap.dump

Пример графика:



Пример статистик до — после:



Еще на всякий случай все сервера мы запускаем с опцией удаленной отладки. Это очень экономит время, когда что-то идет не так, а из логов точная причина неполадок неясна:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=51003

Собственная статистика

Кроме использования уже готовых средств профилирования, мы активно разрабатывали собственные. Так, например, мы логируем каждый спелл, который колдует игрок, замеряя, сколько процессорного времени было на него потрачено. Это позволяет принимать решения о том, какие именно абилки и механики нужно оптимизировать в первую очередь.



Похожую статистику мы ведем и для операций с базой данных, мы знаем не только какие операции были выполнены:



Но и время их исполнения:



Для того чтобы оптимизировать трафик, также приходится делать собственные решения. Поэтому мы замеряем, какие именно сообщения были отправлены, учитывая как их количество, так и объем.



Оптимизации при построении отчетов о тестах

С ростом числа тестов и числа графиков, стало понятно, что заниматься подготовкой теста, его проведением и анализом в одном процессе непозволительная роскошь. В связи с этим, непосредственно анализ результатов теста и построение отчета были вынесены в отдельный сервис, никак не связанный с системой CI. Это позволило освободить время для прогона дополнительных тестов.

Также выделение отдельного сервиса для построения отчетов способствовало появлению единой точки входа для просмотра данных с нагрузочных тестов, боевых серверов или других тестовых стендов.

Наши грабли

Во время тестов очень важно контролировать инфраструктуру, на которой эти самые тесты проводятся. Я уже упоминал в предыдущих статьях, что у нас были проблемы с CPU Frequency Governors, когда искусственно занижалась тактовая частота процесса в целях сбережения электроэнергии. Так вот, мы опять попались на этом. Теперь думаем, как встроить проверку этих флажков в сервер. А в датабазные сервисы, например, мы добавили проверку, что на базах данных настроена синхронная реплика. Потому что её внезапное «отключение» даёт заметный прирост производительности. В общем, советую добавлять проверки окружения непосредственно в сами сервисы. Это дает гарантии того, что ваши серверы оперируются и тестируются именно в том окружении, на которое они рассчитаны.

Выводы

В первую очередь хочется заметить, что нагрузочное тестирование, как и любое другое средство улучшения качества ПО, приносит максимальную пользу только тогда, когда используется постоянно. Да, поддержка тестов требует усилий, но оно того стоит. Лучше потратить эти усилия в спокойной обстановке, чем в пожарном режиме.

Во-вторых, если у вас большая и сложная распределенная система, то, кроме интеграционных нагрузочных тестов, может быть целесообразно также проводить нагрузочные тесты на отдельные компоненты. Это, как правило, дешевле, и такие тесты можно делать более гибкими.

И, в-третьих, нагрузочные тесты полезны еще и тем, что значительная часть обвязки, созданной для их проведения, может очень даже хорошо работать и в боевых условиях.

На этом всё. Как всегда, с радостью отвечу на возникшие вопросы в комментариях.
Автор: @Jimilian

Комментарии (29)

  • +10
    ArcheAge (бедный и угробленный), Armored Warfare, сейчас SkyForge… Причем и над AW и над SF работают Obsidian Entertament…

    БОЛЬШЕ ММО ОТ MAIL.RU!
    • +8
      Господа минусующие, вы верите что хоть что-то способно спасти игровые проекты mail.ru (толковое тестирование, именитые разработчики?), рассчитанные на полуслепых и не очень умных игроков с рефлексом доната? мне так не кажется :).

      Ах, да, я забыл, что у бложика Mail.ru Group есть своя бото-армия, плюсующая пост и минусующая неугодные комментарии. :) Продолжайте, не стесняйтесь.
      • +3
        Вас минусанули 1 раз, видимо всех ботов заняли на нагрузочном тестировании :)
        • –5
          Эм, посмотрите на кол-во голосов к первому комменту. Как только он появился параллельно с набросом + к статье было наброшено и 5 минусов :) Это же mail.ru, мой любимый блог.
        • 0
          офтоп: а как Вы узнали что именно 1 раз?
      • +24
        Пост не об этом. Ребята делают интересную, отчасти уникальную работу, и делятся с вами своим опытом. Дискуссии на тему «Сколько надо задонатить, чтобы нагибать в проектах mail.ru» можно вести в формате оффтопа на игровых форумах, но никак не здесь.
        • –12
          С тем же успехом можно сказать:

          «Пост не об этом. Ребята делают интересный смертельный вирус в своей лаборатории, отчасти уникальную работу, и делятся с вами своим опытом. Дискуссии на тему „выживет ли человечество после его применения и зачем они хотят угробить планету“ можно вести в формате оффтопа на тематических форумах, но никак не здесь».

          Обращаю Ваше внимание, что публикация размещена в хабе GameDevelopment, следовательно, почему бы нам не поговорить о GameDev в разрезе тестируемой игры?
          • +6
            Потому что ваши аргументы никак не относятся к GameDev, слегка относятся к GamePlay, и напрямую к GameMon.

            Сам не в восторге от игр mail.ru, но в техническом плане это грандиозный проект.
    • +1
      Еще был довольно перспективный Northern Blade от отечественных разработчиков.
  • +2
    Будет ли ЗБТ для хабрапользователей? Тут как-никак не только геймеров, но и тестеров предостаточно, и гуру Wireshark тоже ;)
    • +1
      Отдельное ЗБТ — вряд ли. У нас есть Всемогущий Оператор, который сам решает, кого и по каким признакам приглашать на ЗБТ. Знаю только, что нужно, как минимум, зарегистрироваться на sf.mail.ru.
      Профессиональные тестеры, желающие попасть на ЗБТ (и не только), могут использовать workaround :)
      • 0
        Вы клиент под OSX планируете?
        • 0
          Из нашего FAQ
          Появится ли Skyforge на консолях, в Steam или на компьютерах с OS X?
          Skyforge — эксклюзивная разработка для платформы ПК. Если мы решим выпустить игру на других платформах, мы объявим об этом дополнительно.
          • 0
            Вот в этом весь мейл.ру. Просто в одном комментарии.

            Как бы окей, ответ о появлении на консолях дан, но причем тут Steam и OS X к платформе? О_о

            Почитайте, на досуге, и тем кто факи пилит тоже передайте:

            Что такое ПК

            И что такое ОС

            Что такое Steam

            И что такое OS X

            • 0
              Да, признаюсь, процитировать такой ответ было ошибкой. Лучше было бы просто сказать «нет». Думаю, что человек, писавший FAQ, сгруппировал несколько вопросов по одному направлению и выделил ключевой по его мнению. После чего дал общий ответ.

              Написал ответственному, чтобы исправили вопрос и/или ответ.

              А по поводу ваших замечаний выше. Лично я вам минусы не ставил, т.к. сама система минусов кажется мне не очень конструктивной, т.к. обильные минусы лишь повышают градус обсуждения, не увеличивая его конструктивность. Поэтому, пользуясь случаем, прошу участников обсуждения топика быть более сдержанными по отношению друг к другу.
              • –4
                Думаю, что человек, писавший FAQ, сгруппировал несколько вопросов по одному направлению и выделил ключевой по его мнению. После чего дал общий ответ.


                Это одна из грубейших ошибок в предоставлении материалов консультационного характера. За такое мальцы в дверь надо зажимать, ИМХО. И это не общий ответ, это группировка вопросов и ответ только на один из них, т.к. консоль — это платформа, OS X — собственно, ОСь, а steam — вообще магазин\ПО цифровой дистрибуции игр, и уж подвести все это под определение ПЛАТФОРМА физически невозможно.
                Поправьте, пожалуйста, ибо это ужасно.
                • +3
                  Исправить на «Skyforge — эксклюзивная разработка для ПК с ОС Windows» и все все устроит
                  • –1
                    Но согласитесь, отсутствие всего 3ех этих слов превращают пункт FAQ в полнейший маразм.
              • 0
                на самом деле вы так и не дали ответ на мой вопрос.

                Вы за OS X браться будете когда с виндой дело пойдет? Может, я к вам на работу хочу устроится.

                А еще вытащите этот FAQ в пункт меню «ОБ ИГРЕ» — т. е. на sf.mail.ru/game
                Я честно искал перед тем как вопрос задавать.
                • 0
                  Сейчас OS X в планах нет. Есть очень большое желание максимально оптимизировать игру под самую популярную ОС. По данным Steam, 95% их пользователей сидят на Windows. В то время, как OS X — это только 3%.
                  Но планам свойственно меняться, поэтому нельзя исключать появление клиента под OS X в будущем, например, когда подрастёт доля пользователей OS X.

                  Насчёт FAQ передал.
                  • 0
                    Учитывая, что она пока что падает и довольно заметно — видимо пока не судьба.
      • +1
        Эх, объявили бы ЗБТ с наградами (не игровыми, а реальными) за найденные баги и уязвимости, глядишь и сэкономили бы на саппорте в первый год работы.
  • +1
    >И теперь мы можем с одной физической машины запускать в два раза больше ботов — 2к вместо 1к.
    А сколько всего одновременно «играющих» клиентских ботов сейчас? И интересует сколько игроков одновременно зашедших на старте игры выдерживает ваш единый сервер (по крайней мере на текущем этапе оптимизации игры)
    • +2
      В рамках одного теста сейчас 10 000 клиентских ботов. Одновременным их вход не назовешь, они входят за 15-20 минут. Но ограничение такое вызвано в первую очередь самими ботами. Потому что мгновенный вход 200 клиентов из одного приложения работает достаточно медленно, поэтому мы ограничили вход (на стороне ботов) по 6 за раз в одном приложении.
      Так же у нас есть отдельный тест старта, что мы можем провести волну пользователей от стартовой позиции до окончания стартового контента. Там мы тоже стремимся к 10к CCU.
      В принципе, архитектура сервера позволяет выдержать до 100к CCU — было бы железо.
  • +1
    Если не секрет, сервер чата написан с нуля или используется уже какой-то имеющийся на рынке продукт / его часть?:)
    • +2
      С нуля. Готовые решения не устраивали либо по производительности, либо по функционалу, либо по стоимости поддержки: свои баги отлаживать всегда проще, чем чужие :)
  • 0
    еще один вопрос не по теме

    часто играю на minigames.mail.ru в 1000. в этой игра есть один баг достаточно часто (но не регулярно) воспроизводимый. я несколько раз писал в супорт, но они меня мягко игнорят. куда можно/стоит обратится чтобы его пофиксили?
    • +2
      У них централизованная поддержка на многие проекты. Если попадаешь на неисполнительного сотрудника, трудно чего-то добиться. Я у близзов попадался на нерадивых саппортеров.
      Сюда пробовал писать minigames.mail.ru/support?
  • +1
    Планируете ли вы opensource-ить разработки, связанные с нагрузочными тестами?
    • +1
      Спасибо за вопрос.
      Если посмотреть на стек, используемый при проведении нагрузочного теста, то можно выделить следующие элементы:
      • скрипты анализа
      • скрипты управления тестом
      • сервер
      • «клиентские» боты
      • «серверные» боты
      • система статистики
      • система управления серверами

      Сервер, конечно, никто опенсорсить не будет.
      Серверные боты — это достаточно простая штука, которую может сделать каждый желающий для своего сервера за день-другой. Т.е. опенсорсить смысла нет.
      Клиентские боты — очень интересный проект. Самая трудоёмкая часть нашей нагрузочной инфраструктуры, но очень тесно интегрированная с клиентом. Поэтому так же нет возможности для opensource.
      Система управления серверами — пока слишком проектозависима, да и разработчикам не до opensource. Все силы направлены на реальное оперировании.
      Скрипты управления тестом тесно связаны с системой управления серверами. Да и смысла их опенсорсить я не вижу.
      Система статистики — самая проектонезависимая часть. Правда, не прошедшая проверку боем. Не знаю, какая будет судьба с точки зрения opensource, но тут хотя бы есть шанс :)
      Скрипты анализа — тоже шанс есть, но работы там еще непочатый край.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка