company_banner

Нагрузочное тестирование в Skyforge, или Боты – санитары сервера. Часть 2

    И снова привет, хабраюзер!

    Это вторая статья, посвященная тестированию сервера Skyforge. На всякий случай напоминаю, что Skyforge – это MMORPG, сервер которой рассчитан на сотни тысяч игроков и написан на Java.
    В отличие от первой части, где речь идет о роли ботов, эта статья рассказывает о нагрузочном тестировании и метриках.





    Нагрузочное тестирование


    Читатели Хабра знают, что нагрузочное тестирование – это сбор показателей производительности программного обеспечения с целью проверки соответствия требованиям.

    Наши требования к подобным тестам достаточно просты: нагрузка на сервере в «боевых» условиях должна быть в пределах нормы, а user experience не должен страдать. Поэтому при организации нагрузочного тестирования нужно в первую очередь определить, какие условия считать «боевыми». Например, для нас это означает следующее: на двух серверах игровой механики, одном сервере баз данных и одном сервере с разными вспомогательными сервисами резвятся 5000 игроков одновременно. Во вторую очередь нужно определить, какая нагрузка считается нормальной. Мы считаем, что сервер справляется с нагрузкой, если он проводит в обработке меньше 20 миллисекунд за серверный «тик».

    У нас сервисно-ориентированная архитектура — это значит, что топология сервисов во время теста должна совпадать с топологией в «боевых» условиях. Объем контента тоже должен быть приближен к объему, который будет на «боевых». В общем, нагрузочное тестирование – это production в миниатюре, где вместо реальных пользователей – боты.

    Организация тестирования


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

    В связи с тем, что мы ограничены в ресурсах (у нас только одна ботовая площадка), нужно как-то синхронизировать их использование. Поэтому все тесты, использующие ботов, запускаются на выделенном билд-агенте.

    Ночной ботовый тест


    Основной нагрузочный тест, во время которого проверяется весь контент, идет ночью в течение 8 часов. Почему выбрана именно такая продолжительность? Экспериментально было замечено, что самые серьезные ошибки возникают на рубеже 4,5–6 часов, и чтобы их найти, мы просто вынуждены проводить такие длительные тесты. Именно на этот интервал приходится FullGC-пауза (подробнее об этом явлении), борьба с которой также является целью тестов. В наших планах реализовать постоянные тесты длительностью 56 часов в течение выходных. Но пока, к сожалению, это только планы.

    Сервера


    А сейчас я позволю себе дать несколько советов по организации нагрузочного тестирования, попутно рассказывая о том, как оно устроено у нас. Да, я понимаю, что кому-то эти советы покажутся заметками небезызвестного Капитана, но кому-то они все же могут быть полезны.

    Важнейший этап нагрузочного тестирования – выбор и подготовка серверов для тестов. Так как у нас нет боевых серверов, мы выбирали максимально приближенные к тем, которые будут на момент релиза игры. Иначе следовало бы использовать сервера, аналогичные «боевым».
    Сервера должны быть настроены именно так, как будут использоваться в «боевом» режиме. К слову, мы рассматриваем возможность использования технологии Thread Affinity, которая позволяет закрепить отдельные процессорные ядра за конкретными потоками, например за потоками игровой механики. И если эта технология «выстрелит», это будет означать, что данная настройка должна быть включена при проведении нагрузочного тестирования. Иначе поведение сервера под нагрузкой в тестовом окружении и в реальности будет значительно отличаться.

    Также нужно помнить, что на современных серверах есть режимы работы «зеленая среда» или «экономия электричества». Рекомендую отключить их сразу, выставляя процессоры на полную производительность, потому что «в бою» серверам будет не до отдыха, а чинить несуществующие проблемы производительности во время теста в экорежиме – это плохая затея.

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

    Полный доступ подразумевает также, что вы там один. Если вы проводите нагрузочное тестирование, нужно убедиться, что на сервере нет вашего коллеги, занятого тем же самым, а также выяснить, не происходит ли backup базы данных. Нужно быть на 100% уверенным, что вы там один.

    Снимаемая статистика


    Самый простой и самый наглядный способ проанализировать данные по нагрузке – это визуализировать их. Мы используем для построения графиков библиотеку Highcharts, которая уверенно вытеснила jqPlot. Давайте посмотрим на примеры.

    График нагрузки




    Подобный график я вижу каждое утро. Он позволяет отслеживать нагрузку. Нагрузка на сервере – это величина, равная отношению времени в миллисекундах, проведенному в обработке данных за 1 «тик» сервера, к 20 миллисекундам. Если на графике показатель больше единицы (больше нормы), значит, все плохо, если меньше – все хорошо.

    График использования памяти




    Это общий график использования памяти. Он позволяет приблизительно оценить работу «сборщика мусора».

    График работы GC




    Наверное, это один из наиболее важных графиков для Java-серверов. Вряд ли игроки не заметят паузы во время полной сборки мусора. На нем по оси Y отмечена продолжительность той или иной фазы работы сборщика мусора.

    Ключи, которые мы используем для сбора данных о работе GC
    -verbose:gc
    -XX:+PrintGCTimeStamps
    -XX:+PrintGCDetails
    -XX:+PrintGCDateStamps
    -XX:+PrintTenuringDistribution
    -XX:+PrintGCApplicationStoppedTime
    -XX:+PrintPromotionFailure
    -XX:+PrintClassHistogramBeforeFullGC
    -XX:+PrintClassHistogramAfterFullGC
    -XX:+PrintGCApplicationConcurrentTime


    График остановок в Safepoint




    Safepoint – это точка в Java Virtual Machine, где происходит остановка каждый раз, когда нужно собрать stack trace или провести сборку мусора. Подробнее о safepoints можно почитать здесь. На данном графике изображено, сколько миллисекунд за 1 минуту сервер проводит в этих точках.

    График датабазных операций




    А вот прекрасные «шарфики», которые были сделаны по заказу Randll, чей доклад о базах данных вы могли прочесть ранее. Эти «шарфики» позволяют оценивать, какие database-операции и в каком количестве у нас выполняются.

    Кроме этого так же логируется еще несколько десятков статистик, способных рассказать как о высокоуровневых показателях (количество мобов в бою с одним игроком), так и о низкоуровневых (количество переданных пакетов). Большинство этих статистик были заведены в ходе расследований относительно роста нагрузки.

    Для этих же целей с помощью API Yourkit'a мы сделали автоматическое снятие дампа памяти и профиля нагрузки в конце теста. Сейчас они анализируются только в ручном режиме, но планируется автоматизировать и этот процесс.

    Вишенка


    В конце теста запускается так называемый анализатор ошибок. Мы берем все ошибки – а их за ночь иногда набегает до 100 гигабайт – и раскладываем по полочкам. Сравниваем, какие ошибки повторяются наиболее часто, а какие — редко, и разбиваем их по группам. Сортируем по типу – ошибка, предупреждение либо информационное сообщение – и выясняем, является ли это ошибкой контента. Ошибки контента мы передаем QA-специалистам по контенту, а ошибки в серверном коде исследуем сами.



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

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

    Проблемы


    У нагрузочных ночных тестов очень дорогие итерации. Стоимость каждого теста – день. Конечно, мы прикладываем все усилия, чтобы тест проходил каждую ночь, но в реальности успешно он проходит реже, а итерации становятся еще дороже. Любая поломка в любом узле инфраструктуры способна сорвать проведение теста.

    Заключение


    Регулярное нагрузочное тестирование с применением всевозможных статистик – это лучшее средство для здорового сна разработчиков. Сейчас я не представляю, как можно жить без такого рода тестирования, потому что благодаря ему каждое утро я вижу, где у нас полный «аврал» могут возникнуть проблемы. Это помогает нам двигаться в правильную сторону. Спасибо за внимание!

    Другие материалы можно посмотреть на сайте разработчиков Skyforge и в нашем сообществе Вконтакте.

    Спасибо за помощь в создании доклада и написании статьи всей команде сервера Skyforge.
    Mail.Ru Group 789,10
    Строим Интернет
    Поделиться публикацией
    Комментарии 25
    • –7
      С удовольствием прочитал пост.
      • +15
        Ощущение как от чтения ленты в социалке, "oe24 прочитал пост и ему он понравился". Очень важное сообщение.
        • –7
          Это был эксперимент на потенциальный ответ конкретного содержания. Спасибо за участие)))
      • +1
        Интересно, но хочется больше технических подробностей про ботов.
        На чём пишете ботов? Какие типичные ситуации проверяете?
        Допустим, выходит новый контент и все 5000 игроков заходят одновременно и ломятся в один «инстанс». Не наступит ли блекаут в этом случае?
        • +1
          1) про ботов и ситуации можно почитать в первой части.

          2) не ляжет
        • +1
          Из свежего — сейчас проверяем с помощью ботов, сколько аутентификаций в секунду мы держим. Сейчас с помощью ботов получается выдавать порядка 150 логинов в секунду, с которыми сервер справляется уверенно. Поэтому мы хотим увеличить скорость ботовых логинов до 1000 в секунду.
          • +1
            А что в себя включает понятие «логин»?
            Туда входит полный цикл от получения пакета запроса на логин, проверка по базе, загрузка автара пользователя и т.д. до отправки успешного логина клиенту?
            • +1
              Именно так. Только бот не загружает аватара, а идет на следующую итерацию.
        • +1
          для построения таких графиков по GC вы просто парсите логи и выводите в Highcharts?
          • +1
            в данном конкретном случае именно так.
            в принципе, мы еще используем JMX для построения графика использования памяти в Zabbix, но для сбора данных о работе GC мы его не прикручивали.
            • +1
              Ясно. Мы используем в связке с Zabbix'ом продукт Zorka, оно умеет собирать данные по GC. Но хотелось бы чего-нибудь большего причем в одном мониторинге.
              • +1
                А какие данные вы хотите снимать?
                Просто есть такая крутая вещь, как MXBeans может быть среди уже существующих бинов есть нужные вам данные.
          • +1
            Сервер игровой механики работает в одном потоке?
            • 0
              Сам сервер механики многопоточный. И кроме непосредственно потоков игровой механики, в нём присутствуют еще и некоторые служебные потоки: сеть, статистика и прочие. Просто график нагрузки представлен для одного потока — gm4.
            • +2
              Не по теме, но всё-таки
              Зашёл на сайт игры в раздел «Часто задаваемые вопросы»:

              Какая в игре будет боевая система?
              В основе боевой системы Skyforge лежит так называемая target-механика…

              Все как-то стараются уже переходить на нон-таргет, а тут новый проект со старым добрым закидыванием скиллов. Почему? Нет, ответ на сайте я читал, но мне он показался неубедительным.
              • +1
                Ой, вопрос не в бровь, а в глаз.
                Я бы и рад ответить, но боевая система — это NDA.
              • +1
                Также нужно помнить, что на современных серверах есть режимы работы «зеленая среда» или «экономия электричества». Рекомендую отключить их сразу, выставляя процессоры на полную производительность, потому что «в бою» серверам будет не до отдыха, а чинить несуществующие проблемы производительности во время теста в экорежиме – это плохая затея.
                Я правильно понимаю, что на тестовых серверах (а продекшэн? ) вы отключаете CPU Power Management (SpeedStep, Cool&Quiet,P-States, etc)? Действительно, переход из одного состояния в другое, занимает некоторое число тиков. Но обычно нагрузка на процессор меняется достаточно плавно, и таких переходов не очень много. Или у вас сервера всегда загружены на 100%? Если это не NDA, расскажите, пожалуйста, какие проблемы у вас возникали?
                • 0
                  сегодня не мой день. опять промахнулся с ответом. ответил вам ниже.
                  • +1
                    На днях привезли новые сервера для тестов, так что столкнулся с проблемой еще раз.
                    Да, речь идет про SpeedStep, если в Bios он включен, из под root нужно сделать:
                    for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo performance > $i ; done


                    И всё будет хорошо.

                    Проблемы связаны с тем, что 100% загрузка сервера наблюдается, преимущественно, лишь во время сборки мусора. Всё остальное время (во время тестов) процессор загружен где-то на 70-80 процентов. Возможно в этом состоянии у процессора есть соблазн снизить частоту. Мы его от этого соблазна таким образом избавляем.

                    p.s. думаю, что лучше поздно, чем никогда :)
                  • 0
                    Если быть откровенным, то последний раз подобного рода проблемы у нас были больше года назад. И мы, к сожалению, не записали кто именно нам доставил так много «радости», но по косвенным признакам — это был таки SpeedStep.

                    По-хорошему, конечно, сервера должны быть загружены на 100% и работать как Папа Карло, но у нас в тестах пока не так. Тем удивительней было видеть в определенные дни (не всегда), что производительность группы серверов, предназначенных для нагрузочного тестирования, ниже, чем локального компьютера разработчика. Долго разбирались, с чем это связано, пока не нашли причину — «ту самую настройку».

                    Возможно, что SpeedStep не подходит только нам, и у других компаний/команд нет проблем с тем, что сервер работает на меньших оборотах, чем должен, теряя в производительности приблизительно в 2 раза. Но мы натолкнулись именно на такое поведение.

                    p.s. Еще раз, точное название не помню, но скорей всего именно SpeedStep.
                    • +1
                      Статья отличная, спасибо :) Хотелось бы почитать собственно о самом клиенте. У вас там вроде обзор на 40 км обещается?
                      Надеюсь это никак не повлияет на публикацию дальнейших статей?
                      • 0
                        На хабре по тегу Skyforge можно найти в том числе и статью о клиенте. Обзор, картинка — всё как в лучших домах Лондона, и даже лучше. Но будет ли команда клиента писать статьи в ближайшее время мне неизвестно.

                        Что никак не повлияет? Положительные отзывы наоборот мотивируют писать еще и еще :)
                      • +1
                        А реально каким либо образом во время загрузки уровня запечь тени от травы, просто затемнение земли под ней, не точные, а просто пятна?
                        Это, мне кажется очень важный фактор в картинке. Пока ни где не встречал. Мне кажется, это может быть относительно просто в реализации, если с равнивать с бенифитами к реалистичности картинки.
                        • 0
                          Т.к. сам я не занимаюсь разработкой клиента, то для ответа на ваш вопрос призвал Сергея Макеева — нашего тех.дира:
                          У нас для красивого рендера травы есть специальный occlusion шейдер, который делает мягкие тени под кустиками и на «высоких» графических настройках трава отбрасывает честную тень.

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

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

                        Самое читаемое