Дневники разработчиков: Улучшение производительности серверов

$ MRX.BEST $
Забаненный
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
1,990
Реакции[?]
697
Поинты[?]
1K
Обратите внимание, пользователь заблокирован на форуме. Не рекомендуется проводить сделки.
Уважаемые игроки!
В сегодняшнем блоге разработчиков мы хотели бы поделиться некоторыми достижениями, которых добились в улучшении производительности сервера. Кроме того, вы узнаете о новых улучшениях, над которыми мы сейчас работаем.

Версия Unreal Engine, используемая PUBG в настоящее время, основана на модели «клиент-сервер», поэтому статус каждого актора (акторы — это объекты, размещенные на уровнях и представляющие собой персонажей, здания, фоны, камеры и т. д.) должен обновляться сервером для каждого игрока.
Производительность сервера обычно рассчитывается по его «тикрейту» или частоте кадров. По мере увеличения производительности время на кадр будет уменьшаться. А поскольку время на кадр уменьшается, время ответа сервера также улучшается.
Чем быстрее сервер реагирует, тем быстрее ваши действия/перемещения обновляются для других людей. Примером может послужить то, как быстро вы исчезаете с экрана своего оппонента, нырнув за стену. Если мы хотим уменьшить то, что обычно называют десинхронизацией, необходимо улучшать время отклика сервера.​

Перед обновлением #14 сеть работала на сервере Unreal Engine так, как показано ниже:
Для начала объясним вышеописанный поток сетевых процессов. На этапе Net Dispatch пакет, полученный от клиента, обрабатывается на сервере. Например, у нас есть входящая информация — такая как стрельба, передвижение и прочее. Показатели, обрабатываемые во время этого этапа, обычно распространяются по другим клиентам в двух формах: RPC (удаленные вызовы процедур) и репликация. После этого игровая логика (например, физическое моделирование) обрабатывается на этапе Simulate & Render, и результат доставляется всем клиентам через этап Net Flush.
Однако когда RPC отправляются в результате процесса Net Dispatch, это не происходит немедленно: они ставятся в очередь в буфере. Многие вещи, хранящиеся в буфере, отправляются всем клиентам во время этапа Net Flush, а буфер затем очищается.
В данной структуре RPC должен пройти этап Simulate & Render, чтобы попасть из Net Dispatch в Net Flush — это, в свою очередь, приводит к задержке. Вероятно, Unreal Engine был запрограммирован таким образом для того, чтобы уменьшить количество пакетов, отправленных в UDP. Когда количество пакетов сокращается, сеть работает более эффективно.
Было решено, что улучшение времени отклика сервера более важно для PUBG, чем уменьшение количества пакетов. Поэтому в обновлении #14 мы переработали структуру, как показано ниже. Добавлен еще один этап Net Send Flush (до этапа Simulate & Render).
На этапе Net Send Flush все хранящиеся в буфере данные UDP рассылаются, а буфер очищается. Благодаря этому нововведению время, уходившее на этап Simulate & Render, больше не затрачивается — что уменьшает задержку. Во время фазы Net Send Flush не производится обширных вычислений для репликации актора, и ожидающие рассылки данные UDP быстрее уходят.
Поскольку в новой структуре появилось два сетевых обновления: Net Send Flush и Net Flush, скорость обновления сети после обновления №14 удвоилась, из-за чего некоторые люди предположили, будто скорость обращения к серверу (также известная как «тикрейт») увеличилась. Но связано это было не с «тикрейтом», а со скоростью обновления сети, которая поднялась до 60 тиков, поскольку другое сетевое обновление доставляется во время обработки тика сервера.
Эти результаты можно найти в анализе Battle (Non) Sense Update #14. Как видно из приведенной ниже таблицы — когда живы 40 человек, средняя задержка стрельбы снижается с 94,5 мсек до 77 мсек (снижение на 18%).


Так выглядят данные профиля перед обновлением #19 для ПК, снятые 25 июня 2018 года, когда живы 90 игроков:
Время очистки сети составляет 43,2 мс, что равняется 41% от общего времени кадра. Большая его часть используется для «сериализации» — тиражирования каждого актора клиенту. «Сериализация» — это процесс записи данных в память в определенном порядке, доставки статуса актора клиенту через сеть.
Когда мы искали метод оптимизации, основанный на приведенном выше профилировании, то подумали: «Если мы сможем уменьшить количество реплицированных акторов, особенно персонажей, общее время этапа Net Flush значительно сократится».
В отличие от других игр, которые используют выделенный сервер в Unreal Engine, на сервере PUBG одновременно играет до 100 игроков — это значит, что количество акторов значительно выше. Объем данных об акторах — уже проблема, но общее количество участников — еще большая. Задумавшись о способах сокращения числа участников, мы решили, что хорошим решением станет репликация расположенных вдалеке персонажей на более низкой частоте. Поскольку находящиеся далеко персонажи не имеют значения, количество акторов, участвующих в «сериализации», может быть значительно уменьшено без ущерба для игры. В результате время, затрачиваемое на этап Net Flush, уменьшится.
Исходя из вышеприведенной идеи, мы решили внедрить систему, которая пропускает запросы репликации до более подходящей частоты в зависимости от расстояния между клиентом и актором. Мы назвали это «системой чередования репликации». Сначала был доработан раздел, где акторы реплицировались, и понижена частота репликации далеко расположенных персонажей. Затем мы проанализировали проблемы и типы визуальных изменений.
Как только удалось решить сложности, возникшие при уменьшении частоты репликации, мы протестировали, насколько сильно можно снижать данную частоту, и пришли к выводу: снижение частоты репликации до 1/4 от исходной не оказывает влияния на игровой процесс.
Финальная версия системы чередования репликации реализована следующим образом:
  • решить, сколько кадров репликации будет пропущено, в зависимости от расстояния;
  • выполнить один из трех шагов: Шаг 1 пропускает один кадр, Шаг 2 пропускает два кадра, а Шаг 3 пропускает три кадра.
После внедрения системы наш отдел по контролю качества провел тестирование, чтобы найти соответствующее значение расстояния для каждого шага. Результаты тестов показали, что пропуск трех кадров приводил к слишком сильной визуальной дрожи при движении персонажей, поэтому мы удалили Шаг 3. Окончательные значения для каждого шага следующие:
  • Шаг 1 — пропускать один кадр у персонажей, расположенных дальше 70 м;
  • Шаг 2 — пропускать два кадра у персонажей, расположенных дальше 400 м.
Примечание: такие настройки применены на данный момент, но в дальнейшем они могут меняться для улучшения производительности сервера и более плавных движений.
После внедрения новой системы производительность сервера увеличилась на 20%. На приведенной ниже диаграмме мы отслеживали частоту кадров на серверах региона NA, когда в живых было 85 игроков. После обновления частота обновления сервера увеличилась на 22% — с 18,5 до 22,9. Другие регионы также показали увеличение частоты кадров в среднем на 20%.
Не менее отличными новостями стало и то, какие изменения произошли со временем отклика. Вы можете посмотреть видеоанализ обновления #19 на канале Battle (non) Sense.
В приведенной выше таблице видно: когда 85 игроков живы, среднее время задержки для стрельбы уменьшилось на 58%, с 149,4 мсек до 61,6 мсек. Это подтверждает, что проблем с десинхронизацией стало значительно меньше.
Благодаря другим улучшениям скорость тика сервера увеличилась на 20%, а сетевая задержка снизилась на 50% (когда в живых остается более 80 игроков).
Повышение скорости обновления сервера является постоянным приоритетом для команды — с момента запуска PUBG. В дополнение к решению проблем программного обеспечения были усовершенствованы и аппаратные средства. Однако известно, что в последние несколько месяцев перед обновлением #19 игроки не замечали явных улучшений.
Во время кампании #FIXPUBG мы удвоили усилия по улучшению производительности сервера, продолжили исследования и эксперименты с различными идеями, но вы должны понимать, что это очень трудоемкий процесс.
Для реализации даже одного улучшения необходимо провести предварительные исследования, а после его внедрения требуется выполнить большой объем задач по анализу и тестированию. Трудно решить все проблемы за короткий промежуток времени, потому что усилия должны постоянно распределяться на различные задачи. Неправильная реализация улучшений может вызвать большие сложности. Поэтому процесс их выпуска должен идти с максимальной осторожностью и тщательностью.
Пояснив данный момент, мы хотим сказать — после внедрения улучшений, о которых мы уже говорили, начата работа над оптимизацией этапа Net Dispatch. Согласно нашему анализу, на обработку перемещения персонажей уходит достаточно много времени, и мы обнаружили определенные возможности для оптимизации процесса. Движение персонажей оказывает большое влияние на геймплей PUBG. Поэтому мы уделим много внимания решению этой задачи. Необходимо гарантировать, что внедренные улучшения не вызвали проблем с визуальным отображением передвижения персонажей — например, дрожания, которое упоминалось выше.
Мы уже экспериментируем с некоторыми идеями и ожидаем, что затрачиваемое на этап Net Dispatch время упадет более чем на 50% (при нынешних 41,8 мсек), если наши наработки не встретят проблем на этапе тестирования. После успешного внедрения стабилизация данного улучшения займет более месяца, но мы продолжим работать и постараемся внедрить его как можно скорее.
Конечной целью является постоянная планка тикрейта сервера на уровне 30: начиная со 100 игроков и до самой последней пули. Мы приложим все усилия, чтобы вы продолжили получать наилучший опыт игры в Battle Royale из всех возможных.
Благодарю за внимание,
Санг-кюн Ким,
начальник отдела разработки, PUBG Amsterdam
 
Сверху Снизу