Комментарии 7
Круто! Есть вопрос. В шутере куча данных типа плавного поворота камеры. В авторитарном сервере с частичным повторением риплей лога при десинке, может оказаться нужным ворочить кусками памяти. Плюс, не очень ясно, как из Java просто работать с GPU чтобы скинуть туда высокопроизводительные вычисления на бэкенде. Не вызывает ли тут проблем GC и вообще джавовский объектный подход? Вы на этапе проектирования бэкенда думали про другие платформы, кроме Java? Rust, C++, что-нибудь ещё без GC и с прямым управлением всеми ресурсами.
Поскольку я Java разработчик то именно она ближе ко мне, если нагрузка будет возрастать на сервер, то можно прилепить low-latency GC вроде shenandoah zgc и тд. Если и этого не хватает, то на помощь придет горизонтальное масштабирование и балансировка нагрузки. Если нужны GPU вычисления, то конечно же найдутся Java обертки вокруг OpenCL, Cuda и пр. Тем не менее, NodeJS сервера держат огромное кол-во игроков, а именно они используются в большинстве io мультиплееров, и джавовский будет ничуть не хуже. Уверен, что 10 000 игроков в момент времени обработать вполне возможно. Разумеется думал и про C++, это идеальный язык для написания подобного рода вещей, думаю, после того как взлетит мой текущий проект, второй проект будет именно на C++ (libuv, libevent).
Балансировщик уже пробовали прикрутить или только в планах? Если да, то какой?
Event-loop один на процесс? Не смотрели в сторону Vert.x? Он вроде как умеет произвольное количество event-loop'ов запускать.
Хотелось бы увидеть результаты лоад тестов, и ещё комментарии от чего зависит нагрузка на сервере больше, и что выступает узким горлышком: процессор, память или сеть...
Нагрузочное тестирование мультиплеера - дело тонкое, нужен отдельный выделенный мощный сервер, для тестов нужно разграничивать 2 части - это сам netty с nio-обработкой запросов и игровой луп, в данном случае - в виде ScheduledExecutorService, netty может справиться с коллосальной нагрузкой и миллион запросов в секунду, но с игровым лупом ситуация сложнее, зависит от кол-ва вычислений, заложенных в него. Именно луп с вычислениями тонкое место, здесь прямая зависимость от мощности процессора или видеокарты(смотря где они происходят). Думаю чуть позже даже напишу отдельную статью на эту тему, с результатами как раз.
Gatling тесты под свой мультиплеер как таковые не писал, не вижу необходимости, т.к. продукт не готов, скрипты тестов будут очень замудреные, а о большом кол-ве пользователей и говорить не приходится, даже в agar.io пиковая нагрузка состовляла 10k пользователей в ДЕНЬ, вероятно в секунду - не более 1000, это очень мало. Тестировал на своей машине визуально производительность игрового лупа с мок-тестовыми НПС(пользователями), чтобы проверить как вообще двигаются персонажи, на каком этапе усиливается задержка, впринципе, 500 комнат по 20 человек и серверным тиком в 10ms спокойно держит(проц слабенький, 8 ядер, в цикле - обработка коллизий на сеточных моделях и расчеты положения), а дальше начинает поддтормаживать. С хорошей балансировкой нагрузки нескольких нод, думаю 50-100k игроков и более с периодичностью 10ms вполне осилит, а если произвести оптимизации, отказаться от JSON в пользу бинарных данных, то и подавно. В общем, конкретные цифры будут позже в новой статье.
Разработка высоконагруженного игрового WebSocket сервера на Java, Netty с поддержкой BattleRoyale/Matchmaking