После успешной оптимизации клиентской части и серверной архитектуры пришла пора писать механики самой игры для взаимодействия по API — я называю их событиями (они вешаются на какой либо игровой объект на сервере, помещаются в очередь и срабатывают когда придет их время).
Суть работы взаимодействия авторитарного сервера и клиентской части следующая:
Мы создаем группу в которой будут собраны некие игровые механики (например идти в указанную точку, идти в указанном направлении, идти за указанным объектом).
Мы указываем таймаут вызова механик этой группы в секундах или в виде кода по результатам которого будет выдано число с плавающей точкой (например пауза между движениями
1 / скорость * магнитуду направлении, но она может быть и 0 — например на механику получения урона).Мы указываем может ли игрок вызвать механику напрямую (если нет — ее можно будет вызвать лишь из другой механик, например вызов механики получения урона при атаке).
Мы можем указать какие дополнительные параметры могут быть при вызове механики (например объем регенерации жизней или объем урона).
Мы указываем нужно ли рассылать пакет с данными когда механика будет применятся на каком либо существе (например можно высылать время таймаута, доп параметры механики такие как объем урона).
И наконец мы указываем сам код механики который манипулирует параметрами объекта на котором механика сработала и теми объектами которые на карте.
Дополнительно можно указать — нужно ли вешать событие на то же существо когда оно отработает (например регенерацию — нужно).
Таким образом можно создать множество механик которые могут быть вызваны через отправку пакета по Websocket соединению со стороны клиента, а так же вызваны по цепочки внутри друг друга. Плюс ко всему мы можем менять код их работы не меняя ничего в клиенте (если это не затрагивает какую то визуальную часть которая еще не реализована).
При замерах скорости работы на VPS с 2мя ядрами процессора и 4GB оперативной памяти результаты стремятся к 1.000.000 RPS и это только на CPU (в будущем я планирую внедрить параллельные вычисления на GPU), хотя имеются и долгие механики такие как:
сохранение в БД игрока (несмотря на то что оно уже асинхронно делается)
расчет поиска пути при движении до точки
В предыдущей статья я рассказал о горизонтальном масштабировании игрового сервера, так что при достижении работы с сервера к 60FPS (на примере выше он 1000FPS) можно переложить вычисления части открытого мира на другое железо (об открытом бесшовном мире я расскажу в следующих статьях которые вы сможете найти в моем профиле).
В заключение я подготовил пару коротких и не только видео с демонстрацией кода и работы игровых механик проекта (доступен демо доступ на сайте my-fantasy.ru). Впереди еще долгий путь в котором надо будет разрабатывать механики для MMO RPG связанные с физикой.
vasyakolobok77
RPS понятие абстрактное и каждый за ним кроет что-то свое. Покажите конфигурацию системы, настройки ядра ос, методику замера, распределение rps по кол-ву соединений. Без это просто голословные заявления.
Больше походит на то, что вы просто ссылаетесь на публичные теста, а не свои:
webrobot Автор
ссылаясь на публичные тесты я даю ссылку на них. Мои тесты на моем сайте http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=
vasyakolobok77
И где в ваших тестах 1М рпс? именно запросов в секунду - клиент-сервер-клиент, а не вызовы функций-пустышек? и чтобы обработка запроса / тело ответа соответствовали действительности, а не были отдачей hello world?
webrobot Автор
клиент-сервер-клиент - это не скорость обработки в секунду. клиент может быть в Антарктиде и его пинг не позволит сделать такую скорость. Что такое RPS я указал ниже
webrobot Автор
по ссылке что я вам дал указано что актуальные скорости работы механик можно посмотреть онлайн. Как пример есть картинка где в сотых долях от миллисекунды указано время работ механик на момент когда я делал скриншот.
Самая быстрая была 0.001 мс , что это была за механика - я расписал ниже. Если поделить количество миллисекунд в секунде на указанное время получится 1.000.000
Если вы настроены так скептические что не хотите ни во что верить и вчитываться - я не вижу смысла вас переубеждать. Если же вам интересна истина - у меня помимо этой статьи есть и другие плюс я веду видео блог
vasyakolobok77
Меня это зацепило, поскольку я увидел у вас в этом "слепую зону". Вы выдаете желаемое за действительное. То что вы измерили и экстраполировали, это не rps. Изучите более подробно нагрузочное и стресс тестирование, изучите методики проведения замеров, изучите инструменты и сделайте замеры правильно. Это полезная и нужная вещь.
webrobot Автор
то что я выдаю и что измеряю - я не скрывая вам назвал. экстраполяция и интерполяция делается в клиенте. Вы просто пришли с бухты барахты все обругали. Но в моих глазах вы не понимаете о чем говорите
vasyakolobok77
Повторюсь. Я не обругал, а указал на вашу "слепую зону".
Ваше право: или прислушаться и закрыть некомпетентность, или продолжить жить в розовых очках.
Да, я не понимаю вашей прикладной области. Но разработкой приложений и их нагрузочным / стресс тестированием занимаюсь уже давно и имею некоторый опыт.
webrobot Автор
если у вас есть опыт - напишите свои статьи. После уже можно судить по отзывам и критике людей
webrobot Автор
ругать может каждый. а вот сделать что то свое - единицы. так что если вам не нравится то над чем я работаю - просто закройте эту статью и не тратьте свое время
webrobot Автор
RPS - количество обработанных запросов в секунду. Запрос - это отправленная в кучу на исполнение команда игроком или NPC на выполнение какого либо действия. 1.000.000 была самая простая команда - идти в определённую сторону, другие механики не такие быстрые, но и я не все еще реализовал в архитектуре, что я задумал
webrobot Автор
замер скорости работы произведен в виде разницы времени высокой точности hrtime до и после выполнения кода
vasyakolobok77
т.е. вы делали замер на сервере и назвали это rps? теперь понятно почему 1 миллион набралось, если очень постараться, можно и до 1 миллиарда дойти только это ерунда полная.
RPS в обычном понимании - это отправка данных на сервер, обработка на сервере и отдача клиенту. И тут в дело включается весь стек tcp/ip, эффективность работы сети / ос / сервера. И числа будут куда более скромные. Но это будут числа, имеющие смысл.
webrobot Автор
не согласен. то что вы считаете RPS это PING который зависит от местоположения сервера и клиента и времени работы сервера
vasyakolobok77
Это именно RPS. Поскольку без учета задержек на сетевом стеке замеры не имеют смысла. Если вы сделаете обработку запроса в 0 наносек, то по вашей экстраполяции у вас будет бесконечное кол-во rps, что полный бред ))) Но на самом деле, поскольку сетевой стек (не сеть, а именно работа с tcp/ip на уровне ос) вносит задержки, rps упрется в потолок.
И еще одно важное замечание. На кол-во rps влияет кол-во подключений. К примеру, при 100 пользователях сервер может держать 1000rps, но при 1000 пользователях может "задыхаться" и опустится до 100rps. И при нагруз тесте как раз строят график: зависимость rps от параллельных юзеров.
webrobot Автор
вы начали с того что RPS называет кто как хочет. И меня принуждаете назвать как хотите вы. Мой смысл измерить скорость работы механики. PING у меня измеряет другой показатель. Пропускную способность канала - третий.
То что вы описываете про пользователей не RPS, а FPS (который у сервера свой, по умолчанию 1000 максимальный) он зависит от количества ядер, количества запуска механик игроков которые тратят время включенное в RPS.
Я не обязан назвать вашим языком то , над чем работаю сам. А то над чем работаю - не скрывая расписываю
vasyakolobok77
Я не принуждаю называть вещи "моими" именами. Я прошу называть вещи общепринятыми в it терминами: https://en.wikipedia.org/wiki/Web_server#requests_per_second
ping - это время потраченное на отправку и прием ip-пакета (icmp/tcp/udp), работа сервера тут вообще не учитывается.
rps - это в общем случае: время на отправку/прием пакетов + время на сетевой стек ос + время на разбор запроса сервером + время работы условного обработчика.
то что вы измеряете - это время работы обработчика. это время бузусловно важно, но не показывает эффективности веб-сервера в целом.
время на отправку/прием пакетов нам не изменить, оно у каждого клиента будет свое, но в нагрузочном тесте мы его можем минимизировать, делая замеры с соседнего сервера в дц.
а вот на время сетевого стека / время разбора сервером мы можем повлиять, делая тонкую настройку системы и веб-сервера.
FPS - это частота отрисовки кадров (frames) на клиенте, как это применимо к сети не знаю.
webrobot Автор
вас не смущает что вы все это время думаете что у меня веб сервер ? Я не хочу с вами спорить и видно эта статья не для вас - просто пройдите мимо
vasyakolobok77
веб-сервер это общее понятие, в т.ч. сервер работающий по вебсокетам, и в статьях описывался именно такой подход.
все верно, статья не для меня, но комментариями я хочу дать вам направление для развития. по статьям и сайту проекта видно, что вы варитесь в собственном соку и нет обратной связи по вашей работе.
webrobot Автор
1. есть скорость работы сервера websocket на прием и отправку пакетов - она указана по ссылки в виде диаграмм взятых с публичных тестов на hello world и составляет 2 000 000 запросов в секунду при работе как web сервер и достаточной пропускной способности - вы это называете RPS web сервера.
2. Есть команды которые пришли на обработку с websocket сервера игровому серверу (это не веб сервер и не websocket это вообще другой процесс и другая программа которая обменивается по шине данных), который представляет собой демона крутящегося в бесконечном цикле называемом кадры (FPS) и устанавливается от 60 до 1000 (и падает при большом количестве игроков) - он указан в самом верху выделенной на картинке области
В каждом кадре игрового сервера отрабатывают разные игровые механики (с картинке выше в выделенной области - это могут быть команд игроков Request в том числе и порожденные ими механики) у них есть разная скорость отработки которую можно охарактеризовать как RPS что означает сколько таких механик ИГРОВОЙ сервер может обработать в секунду если в теории будут только они , но тк в одном кадре не одна механика а целая куча (запускается внутри цикла еще один цикл который обрабатывает каждое живое существо и в нем еще один цикл который обрабатывает все навешанные механики на конкретное существо ) и целая куча существ то FPS сервера не равен RPS, а значительно ниже.
В теории если скорость самой быстрой игровой механики 0.001 мс то игровой сервер может обработать 1.000.000 этих механик в секунду и можно сказать что именно игрового сервера RPS равен 1М тк он не рассылает ни пакетов и ничего не знает о соединениях (как уже сказал это вообще другая программа)
websocket сервер - это не веб сервер который на каждый запрос что то должен отдавать и нельзя здесь применить как к веб серверу прицип запрос - ответ и высчитать время как с web сервером тк websocket сервер может не отдавать ничего или отдать когда игровой сервер пришлет ему новые данные, а игровой сервер в свою очередь так же не сразу обрабатывать поступившие к нему данные, а складывает их в кучу и, когда придет время игровой механики и ее очередь, рассчитает результат и вернет websocket серверу (за это время игрок может еще кучу команд отправить)
Если у вас есть свой вариант как вышеописанный функционал обозначит какими терминами указать мне на странице тестов - welcome
webrobot Автор
скорость обработки именно запросов зависит от пропускной способности сервера.
webrobot Автор
если вас интересует пропускная способность канала websocket на этом проекте то она расписана в статье https://habr.com/ru/articles/670296/
webrobot Автор
и как вы сами заметили каждый под RPS что то свое кроет - вы там кроете ping который у всех разных и ничего о скорости именно сервера не говорит