Всем привет, мои космодрузья, с вами технический директор 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 минуты реального времени. Нетрудно догадаться, насколько сильно эта разница повлияла на бой.

(Ось Y - количество секунд, между нажатием кнопки модуля и началом его работы. Ось X - время, - прим. переводчика)

В чем причина такой значительной разницы? Ну, мы не можем быть уверены на все 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

[#] 25.01.2014 @ 08:22 by Kanade
+ 1 -
Все это никак не объясняет того, почему н3 флоты могли стрелять, а кфк и хк нет. Просто посмотрев лулзы хк/кфк дредов нетрудно обнаружит, что в каждый по вписывалось по многу народа, включая титаны, у которых пушки работали совершенно нормально. ответить
[#] 25.01.2014 @ 13:31 by Vastak
+ 1 -
НЦ могли стрелять, тк они прогрузились заранее, а проверку и снятие имуна по прогрузке ссп делать не хотят(1 относительно сложно, второе породит эксплоит "неуязвимых курьеров").
Нагрузку на сервак со стороны дронов можно значительно ослабить, упростив просчет групп дронов, да и часть ии можно отдать клиенту лопатить, можно запретить не кап флоту использовать дронов итд итп.
В итоге весь смысл, дроны зло, и тк ССП не в курсе как пофиксить нагрузку от них, то они решили понерфить дронов начиная с Рубикона 1.1 чтобы подобные форматы не использовались так активно.
Короче русская школа - решают не проблему, а ее последствия. ответить
[#] 25.01.2014 @ 15:27 by ShkiperL
+ 2 -
ага блин - у нас сервера несправляются с нагрузкой от дронов - давайте их уберём!
этож разгрузит офигенно сервак и можно будет в локале 10к народа собирать! ответить
- [#] 27.01.2014 @ 14:32 by Ascard
+ 4 -
Товарищ, а ты вообще разбираешься в написании игровых серверов и возникающих при этом проблем? Вот мне, как человеку который чуть-чуть в теме как это делается, наоборот очень отрадно читать такие блоги. Да и ССР молодцы, движут процесс, правят ошибки, собирают статистику, оптимизируют софт. ТД вообще, имхо, был гениальной идеей. Проблема, кмк, в том что они упёрлись в извечную беду всех серверов, когда уровень нагрузки быстрее чем производительность железа и оптимизация кода. Только вот игроки не понимают и продолжают подбрасывать на вентилятор. А выходов тут у них не много. Из самых очевидных : или упрощать механику боя, по сути сводя на нет все трекинги, оптималы, и прочий матан, до банального попал-не попал по рандому. Убирать лишнее, как в Жите, где нету ни посов, ни неписи. Или распаралеливать бой на несколько серверов сразу. Но это тот ещё пизд*ц, хотя и сулит в перспективе отсутствие, хотябы частичное ТД, и увеличение эпичности лагалищ в разы, как и появление новых десинков и эксплоитов. По идее ихняя, по сути, пошаговая система должна неплохо размазаться ещё на пару сервов, но ССР виднее. Врядли они пойдут на ограничение количества пилотов в бою. На введение спец модулей против лагалищ тоже врядли стоит надеятся, так как это изменение игрового процесса которое надо будет чем то контр-балансировать. Именно поэтому убрали аое ДД у титана - ему не было контры.
Вот такое вот моё имхо :) И вообще побольше думайте и поменьше нойте, и будет всем хорошо. ответить
- [#] 29.01.2014 @ 07:19 by LegaRoSS
+ 0 -
В бою B-R5RB, в одном из флотов было сообщение о том, что ССР ограничивают локал числом в 2200, через час времени он стал 2300, в пике 2900, возможно бустили. По борде суммарное количество кораблей в системе за 22 часа боя - больше 5.300... ответить
- [#] 29.01.2014 @ 13:10 by Ascard
+ 0 -
временные ограничения не в счёт. их же сняли постепенно. я имел ввиду постоянные лимиты, вроде, не более 4000 лиц одновременно на систему в любой момент. ответить
[#] 25.01.2014 @ 15:31 by lBlacklWarriorl
+ -4 -
Решение вобщем то есть довольно банальное и простое для дронов. Ввести какой нить модуль для кораблей класса капитал/суперкапитал/титан что нить типа думсдея который лупит только дронов в радиусе грида причём всех подряд. Тока сделать 3 вида модулей скажем: для каров, для суперов и для титанов соотвесно с разными параметрами (типа там радиус поражения, количество дамага и т.п.). Или ввести бомбы для бобров которые лупят тока по дронам. И как мне кажется изобретать велосипед не надо. Один залп и нагрузка падает и пилотам жить легче и проблема дроновых форматов отпадёт сама сабой.

Повторюсь это только моё личное видение проблемы и не претендует на исключительно правильное и верное решение проблемы. Может это будет какая нить промежуточная мера пока ССРшники не придумают что делать. ответить
- [#] 29.01.2014 @ 14:06 by LegaRoSS
+ 0 -
Ты наркоман или никогда на каре не летал... В дрон бэе у нее легко может быть под 1000 дронов, столько же во флитангаре с карго.

И то что ты описываешь уже есть в игре, фитится на т2 фригаты и называется Бомблаунчер, проблему не решает вообще. ответить
[#] 26.01.2014 @ 02:10 by goha
+ 2 -
нам обещали супер отдельный сервер для этой битвы. А итог один массовый слив тех кто заходил в систему. ответить
[#] 27.01.2014 @ 15:10 by The Bandid
+ 2 -
К сожалению проблема гораздо сложнее, чем может показатся неподготовленному человеку. В статье не зря говорится, об экспоненциальном росте как нагрузки на сервер так и объёма данных которые надо передать. Можно сделать нехитрый подсчёт, что если нам нужно о каждом дроне передать хотя бы:
1. Его номер в гриде - 2 байта (позволят нам задеплоить теоритический предел около 65к дронов одновременно)
2. Номер атакуемой дроном цели - 2 байта
4. Его координаты в пространсве x,y,z - 12 байт если каждая компонента имеет тип float
Это мягко говоря оптимистичный сценарий, на деле передаётся конечно больше, но для простоты представим что на каждый дрон надо игрокам передать только эту информацию, суммарно 16 байт.
В стаьте указано количество задеплоиных дронов 38352, умножаем на 16 байт, получаем 613632 байт (около 600Кб) данных о дронах нам нужно передать игроку чтобы его клиент мог хотя бы отрисовать картинку. Вроде бы немного, но эти данные нужно передать каждому игроку, а их в бою принимало участие около 4000. Давайте умножим 600кб на 4000 игроков и получим 2400000 Кб данных, или ВНЕЗАПНО 2,3 Гб данных сервер должен ФОРМИРОВАТЬ по пакетам и ПЕРЕДАВАТЬ игрокам об одних только дронах. Это без учёта других данных о бое, накладных расходах и так далее. Что бы это не лагало передавать надо хотя бы раз в секунду, это просто нереально на современном уровне развития сетей и вычислительной техники.
И простого решения тут просто нет.
Поидее что бы дрон-форматы не ложили сервер ССП возможно придется вводить максимальное количество дронов которые можно задеплоить в гриде, так как у кораблей есть такая характеристика как пропускная шина для дронов, можно ввести максимальный размер шины в гриде (типа если больше то сигналы наичнают мешать друг другу), и пропускную шину каждого корабля уменьшать пропорциоанльно свободной общей шине грида. Т.е. если сумамрная шина вссхе кораблей в гриде равна 100Гбит, а максимально разрешенная шина грида допустим 50Гбит, то индивидуальная шина каждого корабля уменьшается в 2 раза. Да все смогут задеплоить в 2 раза меньше дронов :) Но это пенальти пропорвионально для всех, поэтому это честно, ну или вы можете взять не дроновый формат, тогда эта проблема вас не коснется. Опять же нельзя будет повалить ноду просто выкинув дохуя дронов. ответить
- [#] 27.01.2014 @ 15:28 by The Bandid
+ 0 -
Само собой это породит разнообразные неочивидные кейсы вроде того, что у нас суммарная пропускная способность кораблей в гриде постоянно меняется (появляются новые корабли, помирают старые), и соответсвнено рпидется отзывать/отключать дронов которые начинают невлезать в шину, что выглядит довольно некрасиво с геймплейной точки зрения.

Как альтернатива можно сделать какую-то такую механику, что участники конфликта-мегазарубы должны зраание известить ССП о планируемой драке и о том какие корпы/альянсы планирую воевать на каждой стороне. Тогда ССП мог бы сделать индивиадульный максимум дронов которые возможно задеплоить для каждой стороны конфликта. Соотвесвтенно каждая сторона зарание зная свой лимит сможет адаптировать свой состав по дрон/недрон шипам что бы максимально эффективно использовать свой лимит шины.
Тут опять же возникает вопрос что делать с теми кто незаявлен на мега-махач? Ну тут видимо придется просто ограничить вход в бой тем кто незаявлен на зарубу, что бы играть без лагалова. ответить
- [#] 27.01.2014 @ 17:05 by Ascard
+ 0 -
В общем мысли верные, но вот расчёты не верные. Во первых ты не учёл того что ещё есть такая штука как сжатие, и такая структура будет неплохо сжиматься. Кроме того всю эту инфу не надо передавать каждую секунду, такого издевательства ни один сервер не выдержит, и за такое надо программистов по рукам бить, тежёлым и тупым чем нибудь, топором например. В основном передаётся начальная инфа (прогрузка грида), а потом только изменения состояния (...корабль Х умер, корабль Y начал движение вперёд, и т.д....). Кроме того есть такая штука как интерполяция. Это когда клиент игры продолжает рисовать что твой/соседний корабль летит прямо пока сервер не скажет что корабль на самом то деле уже умел/сменил курс. Некоторые действия клиент может вполне и сам просчитывать, для этого ему не нужен сервер. В основном всякие там расходы патронов и капы, анимация полёта кораблей и т.д. Это всё сильно разгружает сервер. В идеале им конечно часть логики перенести бы на клиенты. Также им очень помогает то что сервер у них по сути не в реальном времени всё обсчитывает, а по тикам. Это как в пошаговых стратегиях - 1тик это 1ход. Просто они считаются быстро и незаметно, в большинстве случаев, для игроков. Такая система, в теории сравнительно легко масштабируется горизонтально - раскладывается на несколько разных серверов, но там нюансов своих тоже вагон конечно. Если такое решат реализовать, то секса у них будет столько что все бордели в городе закроются по банкротству. А вообще, они молодцы :) ответить
- [#] 27.01.2014 @ 18:42 by The Bandid
+ 0 -
Если протокол передачи данных бинарный, а не какой-нить json, то сжиматся эти данные будут плохо, ибо энтропия бинарных форматов данных и так как правило близка к нулю :( А сжатие между тем будет отнимать драгоценный CPU
С распараллеливанием расчетов между серверами тоже больше вопросов чем ответов, относительно несложно распаралелить разные системы/консты как оно сейчас и есть, вприцнипе несложно распаралелить бои в разных гридах, где корабли не взаимодействуют друг с другом напрямую. Распаралелить бой в одном гриде будет очень трудно, т.к. всем параллельным процессам нужно работать с общими данными, т.е. кроме проблемы передачи данных клиентам придется синхронизировать и поддерживать консистентость данных между серверами, что само по себе является нетривиальной проблемой для системы реального времени. ответить
- [#] 27.01.2014 @ 19:42 by Ascard
+ 0 -
я практически уверен что работой с клиентами и их подключениями у них занимается отдельный балансировщик, который в числе прочего берёт на себя все заботы по шифрованию/сжатию протокола, очистки его он невалидщины и прочей рутиной. а на сервер попадает только аккуратно оформленные, почищенные, и собранные в кучку данные. энтропия бинарных форматов не сильно отличается от энтропии любых других форматов, именно в силу своей форматности, то есть структурированности и повторяемости отдельных элементов. обычным, не специализированным текстовым, алгоритмам сжатия глубоко пофигу что у них на входе - быйты или байты которые человек распознаёт как слова.
распаралелить в одном гриде в общем случае не сложнее чам распаралелить в друх гридах. с распараллеливанием вообще всё сильно зависит от того в каком состоянии у них там код. если они имеют клубок спагетти (скорее он "имеет" их), то удачного им сек... половой еб*и. если же изначально писалось с продуманной архитектурой.... в общем то проблема синхронизации решается елементарно, с вынесением состояния на внешний ресурс. в какойнибудь аналог memcached, с автосинхронизацией по сети, локами и прочими шахматами и проэтассами. если оно на это будет прозрачно переключаться, например при ТД 90%, то народ почти не заметит изменений. консистентность будет какраз общими данными и обеспечиваться. в общем - проблема решается, главное не зассать и начать писать. ответить
- [#] 27.01.2014 @ 22:46 by The Bandid
+ 0 -
Вы меня извините но Вы некомпетентны. Алгоритмам сжатия НЕ всё равно какие байтики на вход подаются. Суть всех алгоритмов сжатия как раз в снижении энтропии сообщения. А вас послушать так можно сжать данные, потом результат сжатия снова сжать, потом снова и так до бесконечности пока оно в ноль не сожмётся, ведь байтики они и есть байтики...
Я вот давненько писал сервера высоконагруженные реалтаймовые, на которых всякие Ростелекомы и Центртелекомы спокойно работали, а сейчас в wargaming-е работаю, правда код руками уже не пишу, и вижу что проблемы перед CCP стоят нешуточные. А диванные теоретики такие диванные...

PS. а то что вы про синхронизацию данных пишете вообще лол ответить
- [#] 27.01.2014 @ 23:07 by Ascard
+ 0 -
переходите на личности и заставляете оправдываться? ай яй яй
я не говорил что алгоритмам сжатия вообще все равно что на входе. я говорил про структурность форматов и наличие в них повторяющихся, а следовательно, сжимаемых частей. какая в общем то разница как мы шлём серверу данные, в json-е, xml-е, ещё в чём или просто потоком без оформления разделителями для последующей нарезки побайтово - если оно сжимается.
что касается компетентности, то ваша уже заметна сразу после подсчёта байтиков и предложения слать 600кб каждую секунду. теперь я понимаю как с такими программистами сервера танчиков умудряются лагать.
про синхронизацию не всем будет понятно (тут не только вы читаете) и не всем интересно. я написал упрощённый вариант. понятно что синхронизация данных между серверами в реалтайме это адов звездец. и что php-шный memcached я тут только для примера привёл.
сию дискусию, дабы не усугублять и не перейти к взаимным оскорблениям, предлагаю завершить. или продолжить без переходов на личности. и желательно предметно и с примерами. спасибо за понимание. ответить
[#] 27.01.2014 @ 19:07 by The Bandid
+ 0 -
Ещё вариант нерфа дрон-форматов выглядит "кривой" дорожкой по следующим причинам:
1. Даже если игроки не будут летать на дроновозках на КТА, они всё ещё могут летать на шипах способных задеплоить 5 и более дронов и производить одновременный деплой дронов в целях эксплойта системы, с целью завалить ноду или создать сильный ТД, что бы иметь больше времени для принятия решений и регрупа в системах незатронутых ТД. Т.е. проблема в общем то останется нерешенной.
2. Зависимость вопросов внутриигрового баланса от технических особенностей выглядит как принципиально неправильное решение.

Как вариант решения проблемы через баланс, можно попробовать апнуть дронов, но при этом порезать максимальное количество дронов окторое может задеплоить корабль (допустим сделать 1-3 для обычных кораблей, и до 5 штук для каров). Т.о. дрон-шипы не потеряют в ДПСе, однако количество дронов которое возможно одновременно задеплоить уменьшится. ответить
- [#] 27.01.2014 @ 19:54 by Ascard
+ 0 -
2) зависимость вопросов баланса от тех особенностей у нас везде сплошь и поперёк. достаточно всмомнить бидносферу, которая пилилась спецом под лаги.

балансить дронов нету смысла, это лечение симптомов а не болезни. чем больше они будут апать/резать дронов ради лагов, тем больше будут лагалища. да, там конечно ещё кучу всего можно наоптимизировать, вроде просчёта агры дронов группами. но это именно оптимизации, а не баланс. судя по их графикам и таким вот дев блогам, в железо они уже упёрлись. скоро подтянут софт, и всё. только кардинальные решения. ответить
[#] 28.01.2014 @ 20:32 by AntonNaumenko
+ 0 -
Первый нерф дронов уже пошёл. Ещё пару тройку, и влияние дронов на торможение сервера исчезнет естественным, так сказать, путём. ответить
[#] 28.01.2014 @ 22:16 by Laonda32
+ 0 -
Ломай Еву , участвуй в битвах! ответить
[#] 29.01.2014 @ 14:11 by LegaRoSS
+ 0 -
Кстати как вариант можно запилить деплойбл структурку (это ж модно нынче) которая будет выбивать дронов из управления. Не то чтобы это решало проблему 20к заранее заабандоненых дронов, но хотябы не будут нагружать инфой по дамагу и обработкой выбора цели, не считая отбивания интереса к капитал центри формату... ответить

Написать комментарий
 
EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. CCP hf. has granted permission to EVE-RU to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-RU. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.