Pull to refresh

Comments 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).

Спасибо, очень круто, пиши еще!

  1. Балансировщик уже пробовали прикрутить или только в планах? Если да, то какой?

  2. Event-loop один на процесс? Не смотрели в сторону Vert.x? Он вроде как умеет произвольное количество event-loop'ов запускать.

  1. Балансировщик можно прикрутить любой, взависимости от того какая платформа будет под ним, пока до этого не дошло. Вероятно haproxy будет вполне достаточно

  2. Да, VertX хороший фреймворк, но пока не пробовал.

Хотелось бы увидеть результаты лоад тестов, и ещё комментарии от чего зависит нагрузка на сервере больше, и что выступает узким горлышком: процессор, память или сеть...

Нагрузочное тестирование мультиплеера - дело тонкое, нужен отдельный выделенный мощный сервер, для тестов нужно разграничивать 2 части - это сам netty с nio-обработкой запросов и игровой луп, в данном случае - в виде ScheduledExecutorService, netty может справиться с коллосальной нагрузкой и миллион запросов в секунду, но с игровым лупом ситуация сложнее, зависит от кол-ва вычислений, заложенных в него. Именно луп с вычислениями тонкое место, здесь прямая зависимость от мощности процессора или видеокарты(смотря где они происходят). Думаю чуть позже даже напишу отдельную статью на эту тему, с результатами как раз.
Gatling тесты под свой мультиплеер как таковые не писал, не вижу необходимости, т.к. продукт не готов, скрипты тестов будут очень замудреные, а о большом кол-ве пользователей и говорить не приходится, даже в agar.io пиковая нагрузка состовляла 10k пользователей в ДЕНЬ, вероятно в секунду - не более 1000, это очень мало. Тестировал на своей машине визуально производительность игрового лупа с мок-тестовыми НПС(пользователями), чтобы проверить как вообще двигаются персонажи, на каком этапе усиливается задержка, впринципе, 500 комнат по 20 человек и серверным тиком в 10ms спокойно держит(проц слабенький, 8 ядер, в цикле - обработка коллизий на сеточных моделях и расчеты положения), а дальше начинает поддтормаживать. С хорошей балансировкой нагрузки нескольких нод, думаю 50-100k игроков и более с периодичностью 10ms вполне осилит, а если произвести оптимизации, отказаться от JSON в пользу бинарных данных, то и подавно. В общем, конкретные цифры будут позже в новой статье.

Sign up to leave a comment.

Articles