01:21 Битва в HED-GP: техническая ретроспектива | |
| Всем привет, мои космодрузья, с вами технический директор 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 – наоборот, резко возросла, увеличивая также и количество «опоздавших» команд! | |
|
| |
| Всего комментариев: 0 | |
