По просьбам читателей привожу описание тестирования транспортной части серверного решения на облачной технологии, которое я описывал в прошлой статье. Вначале хочу немного описать, что это такое и для чего его тестировать. Начав свои разработки с построения серверных решений для высоконагруженных ММО проектов в реальном времени, постепенно пришёл к выводу, что для поддержания максимально большого количества клиентов необходимо использовать полностью распределённую систему. Ниже приведу тезисы, на основании которых, разрабатываем сейчас серверные решения.
Существующие на сегодняшний день решения используют данные принципы лишь частично, и построить на их основе действительно облачную систему весьма проблематично. Взять хотя бы движок “BigWorld” в котором применена очень интересная, на мой взгляд, система динамических, плавающих локаций, которые привязаны к объектам системы. Что подходит для огромных бесшовных миров с низкими скоростями изменения. Но как показывает практика, плохо сочетается с быстроизменяющимися играми в реальном времени. Мы использовали раньше подобную технологию и отказались от неё, убедившись, что для реального масштабирования необходимо:
И вот, закончив, наконец, разработку основных модулей облачной системы мы решили протестировать в действии пока одну цепочку
Транспорт – Обработка – Данные.
Transport service
a)для подключения клиентов
b)распаковки/упаковки команд
c)пересылки команд
Work service
a)подключение модулей логики (DLL)
b)передача команд в модули логики
с)обработка команд в модулях логики
d)отправка запросов к SQL и NoSQL
SQL service
a)получение команд
b)оптимизация SQL запросов к базе данных
c)отправка ответов
NoSQL service (objects)
a)чтение объекта по запросу NoSQL
b)запись объектов NoSQL
с)отправка результата
В начале тестовый клиент запускает 1000 параллельных подключений к серверу, которые обслуживает динамический пул потоков. Затем через случайный интервал времени, разный для каждого клиента — отправляется на сервер команда. Сервер получает команду через Transport service, распаковывает её, распознает и передаёт на обработку в Work service. Work service отправляет команду в нужный модуль логики, где происходит её обработка. Отправляется запрос в базу NoSQL для получения нужного объекта, считываются его данные и производятся небольшие вычисления. Затем результат отправляется назад в транспорт сервер на отправку клиенту. Запросы в базу SQL составляют приблизительно ¼ от всех запросов от клиента. Так, как все данные оперативные хранятся в базе NoSQL, а SQL выступает лишь в роли хранилища данных.
Характеристики компьютера:
OS – Windows 2008 server
RAM – 8GB
CPU – i7 (8 core)
SQL – MSSQL
Все сервисы были запущены на 1 PC. Для увеличения нагрузки.
Результаты тестирования для 1 сервиса:
Было произведено одновременных подключений – от 5000 до 10 000 отдельных клиентов (10 тестовых программ по 1000 клиентов каждый клиент асинхронно в параллельном потоке)
NoSQL Количество запросов обработки у которых время задержки не превышает 1 мс – 1200 в секунду
SQL Количество запросов обработки у которых время задержки не превышает 1 мс – 500 в секунду
Для транспортного сервиса (1 инстанс) оптимальное число коннекций — 10 000
По результатам тестов можно видеть, что система, работает стабильно, без сбоев с увеличением нагрузки увеличивается лишь время обработки данных. В реальных условиях сервисы будут запускаться на отдельных PC (распределённая система) и Лоад балансеры будут следить, чтобы время задержки запросов не превышала 1 мс. Данный тест является синтетическим и не гарантирует, что на 1 сервере можно обеспечить работу 10 000 полноценных клиентов динамической ММО игры. Технология является распределённой и подразумевает создание вычислительного облака, состоящего из отдельных ПК объединённых в локальную высокоскоростную сеть. В системе предусматривается вертикальное и горизонтальное масштабирование.
По нашим подсчетам для ММО игры с 10 000 реалтаймовых клиентов потребуется около 10 серверов
Так, как ключевым моментом является скорость расчёта логики игровых объектов.
ОЧЕНЬ ВАЖНО! Сделать быструю логику обработки данных. Мы долго искали оптимальную структуру логики и разработали свою модель, которую назвали «Изолированный расчёт игровых объектов». Данная модель позволяет избежать логических коллизий и максимально упростить расчёт логики для одного объекта. Используя, в полной мере асинхронное программирование и отложеные процедуры.
Для заинтересовавшихся «пощупать лично» после подписания NDA можем предоставить тестовый и админский клиенты
для собственного проведения тестов.
Создавайте, используйте распределенные серверные решения для своих ММО проектов — это поможет в дальнейшем избежать падений серверной части. По всем вопросам — обращайтесь всегда помогу.
- Полное разделение транспортной части проекта от логической части и данных
- Максимальная модульность для создания оптимального решения под конкретный проект
- Унификация сервисов решения (любую команду может выполнить любой из предназначенных для этого сервисов)
- Асинхронное выполнение задач
- SQL предназначена только для постоянного хранилища
- Использование NoSQL для хранения оперативных данных
- Использование системы пулов (многократно используемых групп объектов)
- Нет привязки данных к сервисам обработки
Существующие на сегодняшний день решения используют данные принципы лишь частично, и построить на их основе действительно облачную систему весьма проблематично. Взять хотя бы движок “BigWorld” в котором применена очень интересная, на мой взгляд, система динамических, плавающих локаций, которые привязаны к объектам системы. Что подходит для огромных бесшовных миров с низкими скоростями изменения. Но как показывает практика, плохо сочетается с быстроизменяющимися играми в реальном времени. Мы использовали раньше подобную технологию и отказались от неё, убедившись, что для реального масштабирования необходимо:
- Полное разделение Логики, Транспорта и Данных
- Унификация сервисов одного типа (динамические пулы)
И вот, закончив, наконец, разработку основных модулей облачной системы мы решили протестировать в действии пока одну цепочку
Транспорт – Обработка – Данные.
Transport service
a)для подключения клиентов
b)распаковки/упаковки команд
c)пересылки команд
Work service
a)подключение модулей логики (DLL)
b)передача команд в модули логики
с)обработка команд в модулях логики
d)отправка запросов к SQL и NoSQL
SQL service
a)получение команд
b)оптимизация SQL запросов к базе данных
c)отправка ответов
NoSQL service (objects)
a)чтение объекта по запросу NoSQL
b)запись объектов NoSQL
с)отправка результата
В начале тестовый клиент запускает 1000 параллельных подключений к серверу, которые обслуживает динамический пул потоков. Затем через случайный интервал времени, разный для каждого клиента — отправляется на сервер команда. Сервер получает команду через Transport service, распаковывает её, распознает и передаёт на обработку в Work service. Work service отправляет команду в нужный модуль логики, где происходит её обработка. Отправляется запрос в базу NoSQL для получения нужного объекта, считываются его данные и производятся небольшие вычисления. Затем результат отправляется назад в транспорт сервер на отправку клиенту. Запросы в базу SQL составляют приблизительно ¼ от всех запросов от клиента. Так, как все данные оперативные хранятся в базе NoSQL, а SQL выступает лишь в роли хранилища данных.
Характеристики компьютера:
OS – Windows 2008 server
RAM – 8GB
CPU – i7 (8 core)
SQL – MSSQL
Все сервисы были запущены на 1 PC. Для увеличения нагрузки.
Результаты тестирования для 1 сервиса:
Было произведено одновременных подключений – от 5000 до 10 000 отдельных клиентов (10 тестовых программ по 1000 клиентов каждый клиент асинхронно в параллельном потоке)
NoSQL Количество запросов обработки у которых время задержки не превышает 1 мс – 1200 в секунду
SQL Количество запросов обработки у которых время задержки не превышает 1 мс – 500 в секунду
Для транспортного сервиса (1 инстанс) оптимальное число коннекций — 10 000
По результатам тестов можно видеть, что система, работает стабильно, без сбоев с увеличением нагрузки увеличивается лишь время обработки данных. В реальных условиях сервисы будут запускаться на отдельных PC (распределённая система) и Лоад балансеры будут следить, чтобы время задержки запросов не превышала 1 мс. Данный тест является синтетическим и не гарантирует, что на 1 сервере можно обеспечить работу 10 000 полноценных клиентов динамической ММО игры. Технология является распределённой и подразумевает создание вычислительного облака, состоящего из отдельных ПК объединённых в локальную высокоскоростную сеть. В системе предусматривается вертикальное и горизонтальное масштабирование.
По нашим подсчетам для ММО игры с 10 000 реалтаймовых клиентов потребуется около 10 серверов
- Транспорт: 1-2 сервера
- Вычисление: 3-5 сервера
- NoSQL хранилище: 1-2 сервера
- SQL хранилище: 1 сервер
Так, как ключевым моментом является скорость расчёта логики игровых объектов.
ОЧЕНЬ ВАЖНО! Сделать быструю логику обработки данных. Мы долго искали оптимальную структуру логики и разработали свою модель, которую назвали «Изолированный расчёт игровых объектов». Данная модель позволяет избежать логических коллизий и максимально упростить расчёт логики для одного объекта. Используя, в полной мере асинхронное программирование и отложеные процедуры.
Для заинтересовавшихся «пощупать лично» после подписания NDA можем предоставить тестовый и админский клиенты
для собственного проведения тестов.
Создавайте, используйте распределенные серверные решения для своих ММО проектов — это поможет в дальнейшем избежать падений серверной части. По всем вопросам — обращайтесь всегда помогу.
