И снова здравствуйте, хабраюзер! Это вторая статья, посвященная тестированию серверов.
На всякий случай напоминаю, что Skyforge — это MMORPG, сервер которой рассчитан на сотни тысяч игроков и написан на Java. В отличие от первая часть , где обсуждается роль ботов, в этой статье рассказывается о нагрузочном тестировании и метриках.
Стресс-тестирование
Читатели Хабра знают, что нагрузочное тестирование — это сбор показателей производительности программного обеспечения для проверки соответствия требованиям.Наши требования к таким тестам довольно просты: нагрузка на сервер в «боевых» условиях должна быть в пределах нормы, а пользовательский опыт не должен страдать.
Поэтому при организации нагрузочного тестирования необходимо в первую очередь определить, какие условия считать «боевыми».
Например, для нас это означает следующее: на двух серверах игровой механики, одном сервере базы данных и одном сервере с различными службами поддержки одновременно резвятся 5000 игроков.
Во-вторых, нужно определить, какая нагрузка считается нормальной.
Мы считаем, что сервер может справиться с нагрузкой, если он тратит на обработку менее 20 миллисекунд за один такт сервера.
У нас сервис-ориентированная архитектура — это значит, что топология сервисов во время теста должна совпадать с топологией в «боевых» условиях.
Объем контента также должен быть близок к тому, который будет в «боевых».
В общем, нагрузочное тестирование — это производство в миниатюре, где вместо реальных пользователей — боты.
Организация тестирования
Все тесты, в том числе с использованием ботов, на нашем проекте выполняются в системе непрерывной интеграции.В начале теста билд-агент обновляет и запускает сервер, запускает ботов и ждет заданное время, после чего останавливает сервер, анализирует результаты и переходит к следующему тесту.
В связи с тем, что у нас ограничены ресурсы (бот-платформа у нас всего одна), нам необходимо как-то синхронизировать их использование.
Поэтому все тесты, в которых используются боты, выполняются на выделенном агенте сборки.
Ночной тест бота
Основной нагрузочный тест, в ходе которого проверяется весь контент, работает ночью в течение 8 часов.Почему выбрана такая продолжительность? Экспериментально замечено, что наиболее серьезные ошибки возникают на отметке 4,5–6 часов, и чтобы их найти, мы просто вынуждены проводить столь длинные тесты.
Именно в этот интервал и происходит пауза FullGC ( подробнее об этом явлении ), борьба с которым и является целью испытаний.
В наших планах провести непрерывные тесты продолжительностью 56 часов в выходные.
Но пока, к сожалению, это только планы.
Серверы
А теперь я позволю себе дать несколько советов по организации нагрузочного тестирования, попутно рассказывая о том, как оно работает в нашей стране.Да, я понимаю, что кому-то эти советы покажутся записками пресловутого Капитана, но кому-то они все же могут оказаться полезными.
Важнейший этап нагрузочного тестирования — выбор и подготовка серверов к тестам.
Поскольку у нас нет боевых серверов, мы выбрали те, которые максимально приближены к тем, которые будут доступны на момент выхода игры.
В противном случае следует использовать серверы, аналогичные «боевым».
Серверы должны быть настроены именно так, как они будут использоваться в «боевом» режиме.
Кстати, мы рассматриваем возможность использования технологии Сходство потоков , который позволяет назначать отдельные ядра процессора определенным потокам, например потокам игровой механики.
И если эта технология взлетит, это будет означать, что эту настройку следует включать при проведении нагрузочного тестирования.
В противном случае поведение сервера под нагрузкой в тестовой среде и в реальности будет существенно отличаться.
Также необходимо помнить, что современные серверы имеют режимы работы «зеленая среда» или «экономия электроэнергии».
Рекомендую сразу их отключить, выставить процессоры на полную производительность, потому что «в бою» серверам будет некогда отдыхать, а исправлять несуществующие проблемы с производительностью во время теста в эко-режиме — плохая идея.
Важно, чтобы у вас был полный доступ к вашему сайту, чтобы вы могли в любой момент зайти и посмотреть, что там происходит, какие процессы запущены и т. д. Между вами и сервером не должно быть армии злых админов, которые контролировать каждый чих.
Это необходимо по двум причинам.
Во-первых, самостоятельно устанавливая свой стенд и неся ответственность за его состояние, вы лучше представляете проблемы, которые могут возникнуть.
Во-вторых, вы будете иметь полную информацию о том, что происходит на вашем тестовом полигоне.
Это очень полезно при анализе аномалий в полученных данных.
Полный доступ также означает, что вы там один.
Если вы проводите нагрузочное тестирование, вам необходимо убедиться, что ваш коллега на сервере не делает то же самое, а также узнать, создается ли резервная копия базы данных.
Вы должны быть на 100% уверены, что вы там одни.
Собранная статистика
Самый простой и наглядный способ анализа данных о нагрузке – это их визуализация.Используем библиотеку для построения графиков Высокие графики , который уверенно вытеснил jqPlot .
Давайте посмотрим на примеры.
График загрузки
Я вижу такой график каждое утро.
Это позволяет отслеживать нагрузку.
Нагрузка на сервер представляет собой величину, равную отношению времени в миллисекундах, затрачиваемого на обработку данных на 1 «тик» сервера, к 20 миллисекундам.
Если показатель на графике больше единицы (больше нормы), то все плохо, если меньше, все хорошо.
График использования памяти
Это общий график использования памяти.
Он позволяет примерно оценить работу «сборщика мусора».
Часы работы ГК
Вероятно, это один из самых важных графиков для серверов Java. Вряд ли игроки не заметят паузу во время полной уборки мусора.
На нем по оси Y отмечается продолжительность того или иного этапа работы сборщика мусора.
Ключи, которые мы используем для сбора данных о производительности GC -verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintPromotionFailure
-XX:+PrintClassHistogramBeforeFullGC
-XX:+PrintClassHistogramAfterFullGC
-XX:+PrintGCApplicationConcurrentTime
График остановок Safepoint
Точка сохранения — это точка в виртуальной машине Java, где она останавливается каждый раз, когда ей необходимо собрать трассировку стека или выполнить сборку мусора.
Подробнее о точках сохранения можно прочитать Здесь .
Этот график показывает, сколько миллисекунд в минуту сервер тратит в этих точках.
График работы базы данных
А вот красивые «шарфы», сделанные на заказ.
Рэндл , чей отчет Возможно, вы читали о базах данных ранее.
Эти «косынки» позволяют нам оценить, какие операции с базой данных и в каком количестве мы выполняем.
Кроме того, записывается еще несколько десятков статистических данных, которые могут говорить как о показателях высокого уровня (количество мобов в бою с одним игроком), так и о показателях низкого уровня (количество переданных пакетов).
Большая часть этой статистики была собрана в ходе расследований роста рабочей нагрузки.
Для этих же целей используется Вашкит API В конце теста мы автоматически сделали дамп памяти и загрузили профиль.
Сейчас они анализируются только вручную, но есть планы автоматизировать и этот процесс.
вишня
В конце теста запускается так называемый анализатор ошибок.Мы берем все ошибки — а иногда за ночь их накапливается до 100 гигабайт — и раскладываем по полочкам.
Сравниваем, какие ошибки повторяются чаще всего, а какие редко, и делим их на группы.
Сортируем по типу — ошибка, предупреждение или информационное сообщение — и выясняем, является ли это ошибкой контента.
Ошибки контента мы передаем специалистам по контенту QA, а ошибки в серверном коде исследуем сами.
В отчете указывается, сколько раз и в какие периоды времени повторялась ошибка.
Количество косвенно характеризует сложность повторения той или иной ошибки, ее стоимость для сервера (не забывайте, что при сборе каждого стека вызовов на сервере умирает котенок) и приоритет в багтрекере.
Время появления позволяет оценить распределение ошибок за время тестирования.
Одно дело, если ошибки распределены равномерно, и совсем другое, если они начинаются и заканчиваются в течение определенного периода времени.
В будущем мы планируем развивать эту систему, чтобы можно было связывать ошибки с задачами в JIRA и находить ревизию, в которой ошибка была замечена впервые.
Проблемы
Ночные нагрузочные тесты имеют очень дорогие итерации.Каждый тест стоит один день.
Конечно, мы прилагаем все усилия, чтобы тест проходил каждую ночь, но на самом деле он удается реже, а итерации становятся еще дороже.
Любая поломка в любом узле инфраструктуры может нарушить проведение теста.
Заключение
Регулярное нагрузочное тестирование с использованием всевозможной статистики — лучший способ для разработчиков спать спокойно.Сейчас я не представляю, как можно жить без такого рода тестирования, ведь благодаря ему каждое утро вижу, где могут возникнуть проблемы в нашей «спешке».
Это помогает нам двигаться в правильном направлении.
Спасибо за внимание! Остальные материалы можно посмотреть на сайте Сайт разработчика Skyforge и в нашем Сообщество ВКонтакте .
Спасибо всей команде сервера Skyforge за помощь в создании отчета и написании статьи.
Теги: #Разработка игр #qa #тестирование #тестирование ИТ-систем #боты #нагрузочное тестирование #gc #gc #Skyforge #команда allods
-
Опечатки Приносят Google $500 Млн В Год
19 Oct, 24 -
Rbk Money: На Пути К Выздоровлению?
19 Oct, 24 -
Звонок Из Браузера: Инструмент Для Бизнеса?
19 Oct, 24
