Вход
Регистрация
Фиксим лаги: а я приветствую наших новых оверлордов автоматизации
Последние несколько месяцев я работал над кое-какой очень клёвой вещицей, о которой некоторые из вас уже могли слышать - это проект по переделке внутренностей игрового клиента Евы для того, чтобы убрать из него видео и аудио составляющую. Другими словами, облегчить клиент настолько, насколько возможно, чтобы в итоге его можно было назвать легким (lite) или тонким (thin).
Итак, был сделан тонкий клиент (Thin Client™)!
Что может делать тонкий клиент
Основой тонкого клиента является обычный клиент, который вы все используете. Тонкий клиент берёт то же самое ядро и расширяет или переопределяет некоторые части таким образом, что вам больше не нужна звуковая карта (вставьте сюда какой-нибудь "в Еве есть звук?" мем) или графическая карта, чтобы запустить его.
И почему это интересно?
Тонкий клиент требует меньше системных ресурсов по сравнению с традиционным "толстым" клиентом, и в результате мы можем запустить большее количество тонких клиентов на одном компьютере. Тогда как (нормальный?) игрок может одновременно запустить два или может быть три аккаунта одновременно при использовании традиционного клиента, с тонким клиентом можно запустить в несколько раз больше.
Очевидное преимущество подобного клиента заключается в масштабе - мы можем запустить сотни таких клиентов и заставить их сделать что-нибудь.
Это даёт возможность подготовить набор клиентов таким образом, чтобы провести контролируемый широкомасштабный тест. Можно внести изменения в код и провести тестирование в том же самом окружении, чтобы оценить эффект изменений. Теперь мы можем проводить тесты с беспрецедентным уровнем контроля за происходящим и с высочайшей точностью.
Подобные практики уже долгое время используются для тестирования производительности вёб-сайтов, когда непрерывно генерируемый поток запросов используется для поиска узких мест в системе. Однако ближайший аналог, что мы могли организовать в Еве - масс-тесты на Сингулярити, проводимые CCP Tanis.
Масс-тесты дают нам ценные данные, но их очень сложно контролировать, так как приходится иметь дело с группой от 200 до 500 реальных людей. С другой стороны тонкие клиенты - просто бездушные автоматы. Если мы скажем им прыгнуть с крыши, они, образно говоря, проследуют прямо к краю и затем сделают шаг вперед.
Замечательно, но что это значит для меня?
Тонкие клиенты сами по себе не умнее, чем обычный клиент. Если вы запускаете нормальный клиент Евы, он не начинает сам по себе завоёвывать мир, и то же самое верно и для тонкого клиента. Чтобы заполнить этот пробел, мы разработали несколько методов для управления тонкими клиентами. Два из них это наши внутренние проекты Orchestrator (дирижёр, если уж переводить, прим.пер.) и Automaton Project, о которых я расскажу чуть позже.
Имея возможность сказать тонкому клиенту, что он должен делать, мы получили в своё распоряжение невероятный новый инструмент, который можно использовать с потрясающими результатами. А именно:
- Появляется возможность исследовать режим работы, проявляющийся при прохождении огромного количества миссий в одной и той же системе, Rens Effect, так сказать.
- Мы можем методично изучить поведение клиентов во время масштабных флотовых боёв, воспроизводя уникальные для таких боёв проблемы в лабораторных условиях.
- Мы можем рассмотреть Житу (Jita) под микроскопом, чтобы в деталях разобраться с тем, какое влияние оказывают тысячи рыночных транзакций.
- Мы можем выяснить, какая именно замысловатая последовательность (помимо "собрать большой флот и прыгнуть на другой большой флот") действий приводит к черному экрану смерти, когда один флот пропрыгивает к другому.
- Мы можем определить не просто теоретический, но и практический предел производительности для полностью загруженных систем независимо от того, что делают её жители, будь то ожидание в космосе, охота на нпц или что угодно еще.
- И, наконец, мы можем оценить влияние нововведений в игровую механику в широком масштабе. Старые игроки могут припомнить много изменений механики за прошедшие годы, сделанные с целью увеличить производительность сервера, например ограничение в 5 запущенных с одного корабля дронов вместо 10, изменения скорости стрельбы и модификаторов наносимых повреждений с целью ограничить влияние скорострельных орудий.
Новый инструмент позволяет нам нагрузить и провести стресс-тесты самых древних и запутанных компонентов игры.
Хватит ходить вокруг да около, давайте детали
С этого момента пойдут технические детали, так что если боитесь заумных разговоров - лучше пропустите.
Вопрос, напрашивающийся сам собой - как мы этого достигли? В центре решения лежит использование двух простых вещей:
- Подставные объекты (mocking и mock-объекты, дальше буду использовать только английский термин, прим.пер.)
- Наследование классов в Питоне.
Для не разбирающихся в программировании уточню - mocking подменяет один объект другим, практически идентичным оригинальному, но дающему больший контроль. Этот подход часто используется в юнит-тестах и позволяет разработчику тестировать некоторую часть кода отдельно от остального. Использование mocking даёт нам возможность заменить куски кода, зависящие от пользовательского интерфейса, на заглушки, которые ничего не делают.
Вторым шагом было использование наследования для переопределения некоторых частей кода. Приведу простой пример:
Возьмём систему прицеливания. Когда вы начинаете захват цели, будь то корабль, астероид или еще что-то, вы сообщаете серверу, что он должен начать захват цели и сообщить вам, получилось у вас или нет, если цель вышла за границу дальности прицеливания.
На клиенте этот процесс выглядит, как появление новой цели вверху экрана. На тонких клиентах нет пользовательского интерфейса, так что когда код прицеливания получит ответ сервера и попытается загрузить соответствующее изображение, то получит ошибку об отсутствии нужных графических компонентов.
При наследовании от класса, отвечающего за прицеливание, мы может заменить функцию, вызывающую ошибку, на что-то, что будет корректно работать в новых условиях.
Несомненно, это может быть очень полезным для нас, так как позволяет выделить части кода, наиболее подходящие для рефакторинга, где игровая логика и пользовательский интерфейс слишком сильно связанны между собой.
Во многих случаях мы пересматриваем и подправляем очень старый код, так что получается дополнительная выгода с точки зрения обзора старых файлов с более современной точки зрения.
Что же с производительностью?
В среднем тонкий клиент использует от 150 до 200 мегабайт памяти, и хотя не все сопоставят эти числа со словом "тонкий", это очень хорошее начало. По мере совершенствования тонкого клиента появятся и другие способы уменьшить потребление памяти. Что касается цпу, то тонкий клиент слабо загружает процессор. Большая часть нагрузки приходится на первые секунд 30, когда загружается код клиента и питоновские библиотеки, после чего клиент переходит в состояние относительного покоя. К сожалению, когда вы запускаете несколько сотен клиентов одновременно, даже небольшие изменения в загрузке процессора, происходящие одновременно во всех клиентах, могут вызвать проблемы, так что мы стараемся свести потребление цпу к минимуму.
А управление? Как вы говорите, что им делать?
Для проведения тестов мы разработали инфраструктуру под названием Orchestrator, основной функцией которой является настройка сервера и клиента и запуск определённого теста в рамках традиционной "прошел/не прошел" механики.
Единственная проблема в том, что Orchestrator очень требовательная система - ей необходим полный контроль над всем, включая прокси, сервер и клиенты, так что для того, что мы делаем, она оказывается несколько жадноватой. Из-за такой архитектуры Orchestrator не является идеальным кандидатом для широкомасштабного управления клиентами, но всё же позволяет нам проводить целенаправленные тесты с небольшим количеством подконтрольных клиентов.
Что касается Automaton Project, то, хочу заметить, что это название никто кроме меня не использует, так что это просто моё нежное прозвище для этого проекта. Проект является способом запустить клиент и выполнить определённый код локально, вместо того, чтобы управлять поведением клиента удалённо по сети.
Разница между двумя методологиями, используемыми нами для управления клиентами, заключается в том, что одна представляет собой master/slave парадигму, а вторая является группой полностью автономных действующих лиц. Оба подхода имеют свои преимущества и недостатки, и мы не хотим использовать только какой-то один из них, чтобы в итоге не обнаружить, что это скорее причина наших бед, чем спасение.
Так, а когда я смогу поиграться со всем этим?
Не в этой жизни, извините =) Тонкий клиент предназначен только для разработчиков, и хотя многие бы хотели менее требовательный к ресурсам клиент, это не тот робот, которого вы ищете </jedi> ("this isn't the one you're looking for" - фраза, которую Кенноби говорит/навязывает своими джедайскими штучками штурмовикам в 4 части звёздных войн, когда они с Люком прилетают в бар, где наймут Хана Соло, а на улице штурмовики начинают интересоваться их дроидами - прим.пер.).
Что дальше?
Теперь, когда у нас есть такие инструменты, предстоит много работы по созданию тестов с их использованием. Последнее время CCP Veritas игрался с такими тестами и уже откопал несколько интересных направлений по борьбе с печально известным лагомонстром, но я думаю он расскажет об этом в своём собственном блоге.
Что касается меня, то мне предстоит разработать еще кучу API и кода, чтобы клиент мог делать больше полезного. Нашей основной целью является решение проблемы с лагами, но кроме этого я хочу сделать интерфейс для рынка, чтобы можно было эмулировать Житу и гиперактивный рынок. Так же предстоит работа по превращению стада (или стаи? как назвать группу таких автоматов, может армией?) асинхронных автоматов в организованный флот, а так же работа по дальнейшему "утончению" клиента, и так далее до бесконечности
Хочу сделать акцент на одной вещи - нам всё равно требуется ваша помощь. После того, как мы с помощью тонких клиентов и утилит автоматизации найдем причину какой-либо проблемы и выпустим исправления, нам потребуется помощь всех и каждого из вас для тестирования изменений на Singularity. Мы нуждаемся в вашем стремлении помочь нам и в той огромной изобретательности и находчивости, которую проявляют игроки в Еву, для тестирования исправлений.
На этом всё, au revoir!
Сообщение отредактировал Takeshi Ryuu: 26 August 2010 - 16:10
Наверх
