Вход
Регистрация
reported by CCP Masterplan
оригинал
Слушайте
Превед. Я – CCP Masterplan, один из членов Команды Затык (Team Gridlock). Мы в Затыке занимаемся разборками с ухудшением производительности под большими загрузками – в частности стараемся сделать веселее столь характерные для EVE массовые сражения звездных флотов.
Пока CCP Veritas всячески развлекался с включением/выключением модулей, я наблюдал за другой часть нагрузки на сервер. Фигня в космосе. А именно, добавление и убирание фигни, перемещение фигни и как сообщить клиенту что делать с этой фигней.
Возможно вы уже слышали о Destiny и что оно что то имеет делать с физикой. В этом блоге я немного расскажу о том, что именно делает Destiny и как я ее профайлю. Во второй части я покажу как одно улучшение повлияет на мой страх и ужос: рекетоплюющие дрейки.
Тест
Первый шаг в улучшении производительности при высоких нагрузках – научиться воспроизводить ситуации при которых эти нагрузки возникают. Раньше это делалось во время массовых тестов. Но теперь у нас есть чудесные тонкие клиенты и мы можем воспроизвести разные аспекты флотовых сражений в любой момент.
Мы знаем что дрейк сейчас является одним из самых популярных кораблей и мы знаем что он может стрелять ракетами. Все последующие результаты были получены при прокрутке следующего сценария.
* 200 тонких клиентов летят на дрейках (у каждого 3 полностью заряженных хеви миссайл ланчера, изображающих 3 группы ланчеров)
* 100 тонких клиентов летат на других кораблях. Они изображают нагрузку от наблюдателей – других участников боя. Это важный момент, поскольку вычислительная цена ракеты в некоторой мере пропорциональна тому ,сколько клиентов ее наблюдают.
* 1 палка в стиле ‘звезда смерти'. Палка сконфигурирована НЕ отвечать на аргессию.
Каждый дрейк лочит палку. Затем каждый дрейк стреляет по палке пока у него не кончатся патроны. Это соответсвует примерно 5-6 минутам непрерывной нагрузки от ракет.
Количество шипов было выбрано из соображений загнать нагрузку на ноду до примерно 95% во время стрельбы (найдено экспериментальным путем). Это важная цифра, поскольку примерно при такой нагрузке начинают появляться лаги (задержки активации модулей, замедление отклика на команды движения, задержки на пропрыге и так далее) Данные цифры нельзя напрямую сравнивать с основным сервером, поскольку там установлен другой хардвер, но примерная пропорция сохраняется.
Пока нагрузка на сервер стабильна, мы можем закускать разные профайлеры и оптимизаторы чтобы проанализировать как именно распределяются вычислительные мощности. Также мы можем определить улучшения производительности по сравнению с базовыми 95%. Важно отметить, что тест предназначен для обработки нагрузки на Destiny в условиях неподвижного (не варпающего) флота. Так что он не имеет практический ценности для оценки других критических моментов (например пропрыгов в гейт – это отдельная тема). Стрельба из турельного оружия также не рассматривалась, поскольку она вызывает меньшую нагрузку чем ракеты. Но работа идет – как только нам удастся решить проблемы с нагрузками от одного вида деятельности, вклад других в общую нагрузку соотвественно возрастет и они тоже получат свою долю Специальной Любви (тм) Команды Затык.
Я твоя судья, в смысле судьба
Перед демонстрацией результатов работы оптимизатора имеет смысл ближе познакомиться с Destiny. Destiny часто называют физическим движком EVE. И хотя это важная часть Destiny, она также отвчает и за другие задачи.
Для начала несколько терминов
* Стадион (Ballpark): обрабатывает пространство одной солнечной системы, состоит из пузырей.
* Пузырь (Bubble): Небольшой объем пространства в котором могут взаимодейстовать объекты (игрокам известен также под названием ”грид”) Пузыри могут динамически увеличиваться и уменьшаться, они не могут перекрываться.
* Шар (Ball): Объект (корабль, дрон, ракета, астероид, непись, вормхол и т.д.) в пространстве. С точки зрения Destiny все объекты представлены одним или более шарами. Шары круглые.
* Тик (Tick): Destiny работает дискретными тиками. Каждый стадион делает один тик в секунду.
Тонкая машина в центре вселенной
Каждый тик состоит из трех фаз:
1) Пре-тик
* Обновление отношений шаров и пузырей
* Применение команд клиента (варп, орбита, апроч и т.д.) поступивших после окончания прошлого тика.
* Применение событий сервера (взорвать, создать ракету) произошедших после окончания прошлого тика
* Построение обновлений данных для клиента
* Пересылка обновленицй клиенту
2) Развитие
* Переместить шары в соотвествии с текущими действиями
* Вычисление столкновений между шарами
* Вызов обработчиков столкновений
3) Пост-тик
* Обработка новых клиентов (пропрыгнувшх, андокнувшихся и т.д.)
* Очистка
Раз в секунду сервер выполняет всю эту последовательность действий. Если после этого остается свободное время, то сервер обсчитывает другие задачи, которые надо обсчитать. Важно отметить что тик Destiny не блокирует – мы не можем выполнять асинхронные операции вроде запросов к базе данных. Большинство обработчиков событий например просто оставляет задачу для позднейшего выполения в свободное время. Эта задача уже может работать с базой данных – создавать вреки и перемещать персонажей в клонилку.
Именно поэтому при больших загрузках возникают задержки между попаданием ракеты в цель и взрывом цели. Иногда эта задержка может быть настолько большой, что цель успеет отварпать и считать себя в безопастности. Хотя на самом деле она уже умерла, но еще не знает об этом.
Фаза развития является наибоее сложной с точки зрения математики. Именно тут обсчитвается вся физика космического полета (та ее версия, которая используется в EVE). Долгое время считалось, что именно именно на эту фазу уходит большая часть вычислительного времени и соотвественно именно тут его можно будет сэкономить. Поступали даже предложения использовать для этих вычислений графические процессоры – потому что графические процессоры хорошо считают. Однако скоро вы увидите, что фаза развития на самом деле отвечает за такую мизерную долю общей вычислительной нагрузки, что подобная попытка привела бы, учитывая дополнительные затраты на коммуникацию сервера и графического процессора, только к потерям времени.
Наша новая любимая игрушка
Позвольте вам представить самое новое оружие в нашем антилаговом арсенале – профайлер Telemetry. Это утилита для визуализации производительности программ, работающих в реальном режиме времени. Разработана RAD Game Tools.
Мы начали с ней работать этим летом и все время находим ей все новые и новые применения. Telemetry фактически позволяет построить временную последовательность событий по мере выполнения кода и визуализировать полученную картину. В сочетании с тонкими клиентами мы получаем возможность создать нагрузку и затем увидеть ее своими глазами. И это делает Команду Затык счастливой.
На рисунке 1 показан 1 тик работы Destiny по версии профайлера Telemetry. По горизонтали отложено время (увеличивается вправо). По вертикали (увеличивается вниз) показано как начинается и заканчивается выполнение команд в разных секциях таймера. Выглядит примерно как эволюция традиционного стека вызовов, только вместо вызовов функций используются секции таймера. При входе в новую секцию таймера под текущим блоком добавляется новый. При выходе из секции таймера блок удаляется.
(Программисты странные твари – не только начинают считать с 0 вместо 1, но и отращивают структуры вниз, а не вверх. Вот такие мы загадочные)
Рис 1: Типичный тик Destiny во время массового запуска ракет, помечены три основных фазы тика
Из рис.1 очевидно, что на фазу развития затрачивается меньше 10% всего рабочего времени тика Destiny. И при этом большая часть фазы развития затрачивается на вызов обработчиков столкновений – в данном случае обработчиков взрывов ракет. Именно поэтому я и говорил выше, что сейчас не имеет особого смысла ускорять работу кода симуляции.
Большая часть времени тратится в фазе пре-тика. И в основном оно тратится на две операции
1) Определить какие клиенты должны получить инофрмацию из списка шаров которые были добавлены/удалены со времени прошлого тика. Новый шар добавляется когда выстреливается ракета. Старый шар удаляется когда ракета взрывается. Дрейки умеют это делать в промышленных масштабах.
2) Послать обновление информации клиентам, выявленным в предыдущей операции. Дальнейшее расследование показало, что эта операция занимает так много времени в основном из за преобразования внутренних данных сервера в последовательность байтов,которые можно переслать по сети клиенту.
Если мы найдем способ оптимизировать эти две операции, то общаяя нагрузка на Destiny сильно сократится. И, как оказалось, такой способ есть. Но о том, в чем именно он заключается вы узнаете из второй части этого блога
====
вопросы и ответы из топиков на оффоруме
====
фраза drakes of destiny (part 1) и сразу после нее
Hi. I'm CCP Masterplan
чемто меня настолько пробили на хихи что я решил перевести этого слона
автор в оригинале тоже стебется, может не совсем так как я в переводе, но тоже достойно
алсо, для тру-программистов вопрос, что имелось в виду под
It is important to note that the Destiny tick is entirely non-blocking - we can't do any asynchronous operations such as database queries or anything that might cause execution to yield. Most of the collision callbacks, for example, simply schedule a task to be run later.
и насколько адекватно я это перевел
====
Сообщение отредактировал Tester128: 14 December 2010 - 1:22
Наверх
