Всем привет, мои космодрузья, с вами технический директор CCP Veritas. Как некоторые из вас наверное знают, недавно в системе HED-GP состоялся бой. Это случилось не в первый, да и наверное не последний раз. Однако это был выдающийся по своей масштабности и количеству участвовавших (а также слившихся) кораблей. И честно говоря, производительность сервера оставляла желать лучше. Сегодня я хочу рассказать вам о том, почему все было именно так, и как вообще работает наш сервер.

Как многие уже говорили, несколько месяцев назад произошел бой, который по своей эпичности практически не уступал битве в HED-GP. Я говорю о битве в системе 6VDT, которая прошла 28 июля, 2013 года. Производительность сервера в этом бою была значительно выше, чем в битве в системе HED-GP. Я хочу сравнить эти два события, однако для начала я должен рассказать вам, какие именно метрики мы будем использовать.

У нас есть три метрики, с помощью которых мы проводим оценку производительности и стабильности сервера. В большинстве случаев нам достаточно просто взглянуть на степень загрузки ЦПУ. Обычно она не превышает 80%, что означает удовлетворительную производительность и стабильность. Если нагрузка продолжает увеличиваться, то включается механизм Tide Dilation (ТД), поэтому при оценке производительности смотрим на коэффициент замедления времени. Если нагрузка становится еще больше, то в конце концов мы достигнем максимального коэффициента замедления – 10%. Этот барьер был специально установлен нами на 10%, чтобы позволить эпической битве закончиться до ДТ.

Проблема в том, что игроки способны перегрузить сервер даже под 10% ТД, так что нам было необходимо определить еще одну метрику, которая позволит оценить работу сервера, который перегружен настолько, что ему не хватает даже максимального ТД!

К счастью такая метрика у нас уже была, созданная еще до того, как мы ввели ТД. Она называется «опоздание Догмы» (ОД). Догма это система, которая обрабатывает запросы по работе модулей и их эффектов на корабли. А «опоздание» говорит нам о том, как быстро обрабатываются эти запросы. Остроумное название, не правда ли? Как бы то ни было, эта метрика, по моему мнению, лучше всего показывает то, насколько сильно перегруженность сервера влияет на игроков. Она гораздо точнее, чем другие характеристики, показывает, как долго сервер может «тупить», прежде чем начать обрабатывать команды с клиента. Также она измеряет количество времени, необходимое серверу для обработки «опоздавших» команд и возвращения к нормальному режиму работы.

В 6VDT, ОД в пике достигало 42 игровых секунды. С учетом 10% ТД это было 7 минут реального времени. А вот в битве за HED-GP максимальное значение ОД было 193 игровых секунды, или 32 минуты реального времени. Нетрудно догадаться, насколько сильно эта разница повлияла на бой.

В чем причина такой значительной разницы? Ну, мы не можем быть уверены на все 100%, так как во время этого боя нам пришлось отключить наши системы анализа производительности, так как они тоже нагружают сервер. Но у нас есть пара неплохих догадок. Во-первых, увеличившееся количество дронов в гриде, а во-вторых, длительность битвы. Как этот второй показатель влияет на работу сервера можно увидеть по графику выше. Обратите внимание, что первые пару часов нагрузка на сервер в обеих битвах была сопоставимой. Однако затем, нагрузка в битве за 6VDT постепенно начала спадать, а вот для HED-GP – наоборот, резко возросла, увеличивая также и количество «опоздавших» команд!

Начнем с дронов. Мы не можем назвать точное количество активных дронов в гриде в какой бы то ни было промежуток времени, но дать примерную, и при этом достаточно точную оценку мы все таки можем. За время битвы в 6VDT игроки задеплоили 21 123 дрона, тогда как в HED-GP их количество достигло 38 352. На 84% больше, чем в 6VDT. Это не значит, что нагрузка на сервер также была на 84% выше. Тем не менее мы видим, что в HED-GP использовалось намного больше дронов, чем в 6VDT.

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

Таким образом, в масштабных зарубах нагрузка на сервер для n-го количества игроков возрастает не линейно, а экспоненциально. То есть, каждый из n-го количества игроков должен получить информацию по остальным n-1 игрокам. Да, для пушек это тоже верно, но для дронов эта проблема становится куда серьезнее. Во-первых, дроны генерируют больше сообщений к серверу, в итоге чем больше количество игроков, тем выше относительная доля сообщений [на сервер] от дронов в общем количестве сообщений. Во-вторых, процесс принятия решений ИИ для каждого дрона очень плохо масштабируется. Очень часто для выбора цели для конкретного дрона ИИ оценивает все враждебные объекты в гриде. Снова нагрузка растет экспоненциально, когда для каждого дрона из их n-го количества нужно оценить количество объектов равное n + количество враждебных кораблей.

Это решаемые проблемы. Взбодрившаяся в последнее время группа программистов (Team Gridlock), которая занимается проблемами с производительностью серверов, обсудила с гейм-дизайнерами вопрос о будущем дронов в игре. В частности, о том, как можно их пофиксить, как с точки зрения нагрузки на сервер, так и с точки зрения гейм-дизайна. Пока еще неясно, что именно будет в приоритете – работа с дронами или же текущая работа по «опозданию Догмы». Во многом это зависит от того, насколько популярны дрон-форматы будут в будущем, после выхода Рубикон 1.1. Тогда мы сможем более точно оценить ситуацию и возможные пути решения проблемы.

~CCP Veritas

Перевод © Dervish19