Тем, кто еще не успел ознакомиться с первой частью раздела, рекомендую прочитать первая статья где я рассказываю о самой идее API-сервиса.
В этой части будут обсуждаться проблемы, с которыми придется столкнуться.
Асинхронность и масштабируемость
Когда наш сервер обрабатывает запрос игрока на то или иное действие, для расчета требуется время (на момент написания статьи оно составляет ~5-10 мс).Когда игроков тысячи, время увеличивается пропорционально, и последний игрок в очереди ждет, пока другие игроки завершат расчет. Чтобы этого избежать, нужно обрабатывать запросы параллельно.
Подробнее о том, зачем это нужно, можно узнать из моего видео:
Параметры
PHP сегодня работает в двух режимах- ФПМ (тот режим, когда есть один «управляющий» процесс и куча дочерних процессов, которые открываются динамически по количеству обращений к сайту, например) - это процесс с коротким жизненным циклом
- интерфейс командной строки - режим работы переводится как Интерфейс командной строки, но когда слышишь слово командная строка, многие думают, что для работы на экране она должна быть открыта - это не так, на самом деле php скрипт работает как демон на заднем фоне.
Он не имеет условного процесса управления.
Это процесс длительного жизненного цикла
Каждый из них имеет ряд особенностей, с которыми им приходится иметь дело.
Каждую из опций можно вызвать друг из друга (например, процесс CLI можно вызвать из FPM функциями семейства exec, которые тратят на вызов +- 30 мс, а из CLI можно вызвать FPM, отправив запрос поднять процесс напрямую в сокет fpm и даже эмулировать передачу данных POST и GET) Мы можем использовать CLI для управления сервером (скриптом, который слушает запросы пользователей), который создает новые процессы FPM (через сокет) в сервисах (предположим, наша архитектура API будет построена в виде сервисов), не дожидаясь ответа.
(они отправляются и забываются) для поддержания асинхронности.
Также НПС должны жить своей жизнью (идти в атаку) и жить они будут в режиме CLI, о чем я снял подробное видео:
Проблемы
- Так или иначе, на поддержание минимальной функциональности процесса CLI тратится 0,7% процессорного времени (мы рассматриваем сервер с одним ядром) и большое количество NPC «съедают» весь процессор
- PHP выделяет ОЗУ (как в CLI, так и в FPM) процессу больше, чем ее фактическое потребление ~+50% (этот параметр можно посмотреть с помощью функции Memory_get_usage(true)), что при большом количестве NPC-процессов будет « съесть» больше оперативной памяти, чем следовало бы.
Кроме того, количество одновременных процессов PHP FPM ограничено настройками файла конфигурации.
- Каждый раз при запуске CLI в память загружаются обычные PHP-скрипты (сам фреймворк).
- При использовании библиотек типа Apcu (позволяет кэшировать данные в памяти, включая ряд ресурсов, объектов и php-массивов) в режиме Cli мы не можем получить то, что было создано в режиме FPM (и наоборот, так как в FPM этот кеш живет до тех пор, пока php-fpm перезапускается) в CLI до конца работы демона и только в нем самом) и таким образом в CLI нужно искать другой способ доступа к общей памяти
- Но мы не можем работать только в CLI (например, когда приходит запрос от игрока и нам нужно запустить процесс).
Каждый из режимов тратит время на поднятие процесса (новый процесс cli создается из php-функций семейства exec, которые тратят +-30 мс), fpm +-2 мс, а хорошим пингом в играх считается 60 мс.
Решение проблемы
- Для решения проблемы потребления памяти при каждой загрузке скриптов в php используется технология опкэш который по сути разместит всю структуру в общей памяти (эти php-файлы загружаются в начале скрипта через автозагрузку композитора или прямое требование).
Демонстрация его работы на видео:
- Количество одновременных php fpm можно увеличить, изменив настройки самого fpm, однако проблему ниже это не решит
- Объединение НПС и объектов в так называемые управляющие «пулы», которые синхронно управляют десятками или сотнями живых НПС и объектов (например, 1 пул — 1 карта).
Это решит проблему чрезмерного потребления памяти и процессора (ведь поддержание CLI-скрипта, который ничего не делает, требует процессора и так и сяк 0,7%, а 100 CLI-скриптов тратят в десятки раз больше, чем пул из 100 NPC под его контролем).
Пример того, как это будет выглядеть, можно увидеть на видео:
- Мы также не можем использовать общий кеш Apcu (который кэширует ресурсы, объекты и php-массивы без какой-либо сериализации) для доступа к нему с нашими NPC (поскольку они работают в CLI), но мы можем обратиться к библиотекам для работы с общей памятью, например Шмоп и подобное в php
данные будут) Для тех, кому интересна идея моего творчества, есть адрес проекта где я делюсь исходным кодом.
буду признателен за лайк Подпишитесь на мой профиль чтобы не пропустить новые статьи.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Статья лучше по качеству/восприятию, чем первая часть? 47,83% Все равно плохо и ничего не будет работать 11 30,43% Стало немного лучше, но не верю, что намеченный сервис выйдет 7 21,74% Лучше или хуже, но сама идея такого сервиса кажется реальной и полезно 5 0% Стало лучше 0 Проголосовали 23 пользователя .
6 пользователей воздержались.
Теги: #Разработка игр #api #php #unity #unity3d #разработка игр для android #сервер для онлайн-игр #разработка игр для ios
-
Работа С Анимированным Фоном
19 Oct, 24 -
Копировальные Аппараты
19 Oct, 24 -
Nginx 0.7 Стал Стабильным
19 Oct, 24 -
Если Бы Я Жил В Другой Стране...
19 Oct, 24 -
Как Стать Zce
19 Oct, 24 -
Wiki-Статьи, Которые Нравятся Блоггерам
19 Oct, 24
