Для создания любого продукта первым встает выбора скелета проекта на котором он будет работать (фреймворк)
Он должен отвечать требованиям по скорости работы, простоты работы с ним программистами и функциональными возможностями. В настоящее время популярные фреймворки имеют множество зависимостей от сторонних библиотек и , как это часто бывает, из за обще направленности чрезмерно сложные , обладающим функционалом который может никогда не пригодится.
Данный проект - Российский и сделан с уклоном на простоту работы с ним, с минимальным набором зависимостей от других библиотек учитывая опыт работы с западными системами. На данном проекте сделан этот сайт с его сервисами и проекты которые на нем опубликованы
В настоящее время на данном фреймворке ведется разработка проекта для внесения онлайн в игры - подробнее имеется пример ранней версии в github
1 Легкий в освоении (фреймворк состоит из ряда фаилов в папке core/) 2 Архитектура основана на сервисах (независимые приложения в папке app/) легко переводимые на микросервисы (расположенные физически на разных серверах) 3 MVC (разделение кода и представления) паттерн 4 Передерживание принципа SOLID 5 Cледование стандартам PSR 6 Современные шаблоны проектирования (фабрика, синглтон, декоратор, адаптер и тп) 7 Скорость работы (нагрузочное тестирование показало в x30 более быстрый результат чем на фреймворках Symfony/Laravel) 8 Свой собственная ORM/DBAL (гибридный принцип Database First и Object First основанный не на аннотациях классов, а на ключах БД и именовании полей), есть плагин для работы с XML 9 При разработке используются практики современных фреймворков (Symphone, Laravel, Yii) 10 Минимум зависимостей: проект использует лишь то, что реально нужно (легко отслеживать просадки в скорости, потребление памяти, особенно в CLI режиме с многопоточными приложениями) 11 Для администрирования игрового мира используется веб сервис (Аналог CMS для сайтов и CRM для взаимодействия с пользователями)
Результат нагрузочного тестирования HTTP запросами для обычного сайта, указан в в миллисекундах (1 секунда = 1000 миллисекунд).
Инструменты SoapUI, 50 потоков, 5 секунд, кеш отключен) на страницу 404.
На Данном примере видно что помимо нагрузки на сервер имеет место тот факт что Laravel и Symfony не успевают освобождать FPM Child (стандартные php fpm с max_children = 5) и создается очередь ожидания освобождения процесса FPM .
Тем самым даже при увеличении числа max_children до достаточного что бы обработать все запросы параллельно скорость выполнения каждого будет равна параметру "min" в табличке ниже на сервере где производилось тестирование. На более мощных серверах и при использовании кэш показатели Symfony и Laravel можно улучшить в Х10 , но не стоит забывать что и показатели фреймворка "Моя Фантазия" вырастут пропорционально. Скорость Symfony и Laravel обусловлена большим количеством библиотек и overhead на роутинг http запросов
Однако скорость обработки запросов в секунду ограничена скоростью HTTP соединений (который работает на базе TCP) и работой самого PHP FPM . Выбрав медленное из них из данных выше можно сделать вывод что 2 миллисекунды (0.002 секунды) на сервере тестирования занимала скорость поднятия такого соединения и она не будет меньше на нем (те чистый результат работы PHP составляя min - 2 )
В этой части серии статей про разработку сервера для реалтайм игр я расскажу вам о показателе сетевого устройства которое значительно влияет на количество запросов, которое способен обработать ваш игровой сервер.
В статье я расскажу как разработчиков вводят в заблуждение рассказывая что необходимо учесть в первую очередь при разработке серверов (и не только для игр), но умалчивая о реальных "узких местах" (проблемах).
В конце статьи будет приложена видео версия.
Читать далее
