Комментарии 31
При замерах скорости работы на VPS с 2мя ядрами процессора и 4GB оперативной памяти результаты стремятся к 1.000.000 RPS и это только на CPU (в будущем я планирую внедрить параллельные вычисления на GPU)
RPS понятие абстрактное и каждый за ним кроет что-то свое. Покажите конфигурацию системы, настройки ядра ос, методику замера, распределение rps по кол-ву соединений. Без это просто голословные заявления.
Больше походит на то, что вы просто ссылаетесь на публичные теста, а не свои:
согласно публичным тестам, на сервере разработки еще не проверялось
ссылаясь на публичные тесты я даю ссылку на них. Мои тесты на моем сайте http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=
И где в ваших тестах 1М рпс? именно запросов в секунду - клиент-сервер-клиент, а не вызовы функций-пустышек? и чтобы обработка запроса / тело ответа соответствовали действительности, а не были отдачей hello world?
клиент-сервер-клиент - это не скорость обработки в секунду. клиент может быть в Антарктиде и его пинг не позволит сделать такую скорость. Что такое RPS я указал ниже
по ссылке что я вам дал указано что актуальные скорости работы механик можно посмотреть онлайн. Как пример есть картинка где в сотых долях от миллисекунды указано время работ механик на момент когда я делал скриншот.
Самая быстрая была 0.001 мс , что это была за механика - я расписал ниже. Если поделить количество миллисекунд в секунде на указанное время получится 1.000.000
Если вы настроены так скептические что не хотите ни во что верить и вчитываться - я не вижу смысла вас переубеждать. Если же вам интересна истина - у меня помимо этой статьи есть и другие плюс я веду видео блог
Меня это зацепило, поскольку я увидел у вас в этом "слепую зону". Вы выдаете желаемое за действительное. То что вы измерили и экстраполировали, это не rps. Изучите более подробно нагрузочное и стресс тестирование, изучите методики проведения замеров, изучите инструменты и сделайте замеры правильно. Это полезная и нужная вещь.
то что я выдаю и что измеряю - я не скрывая вам назвал. экстраполяция и интерполяция делается в клиенте. Вы просто пришли с бухты барахты все обругали. Но в моих глазах вы не понимаете о чем говорите
Повторюсь. Я не обругал, а указал на вашу "слепую зону".
Ваше право: или прислушаться и закрыть некомпетентность, или продолжить жить в розовых очках.
Да, я не понимаю вашей прикладной области. Но разработкой приложений и их нагрузочным / стресс тестированием занимаюсь уже давно и имею некоторый опыт.
ругать может каждый. а вот сделать что то свое - единицы. так что если вам не нравится то над чем я работаю - просто закройте эту статью и не тратьте свое время
RPS - количество обработанных запросов в секунду. Запрос - это отправленная в кучу на исполнение команда игроком или NPC на выполнение какого либо действия. 1.000.000 была самая простая команда - идти в определённую сторону, другие механики не такие быстрые, но и я не все еще реализовал в архитектуре, что я задумал
замер скорости работы произведен в виде разницы времени высокой точности hrtime до и после выполнения кода
т.е. вы делали замер на сервере и назвали это rps? теперь понятно почему 1 миллион набралось, если очень постараться, можно и до 1 миллиарда дойти только это ерунда полная.
RPS в обычном понимании - это отправка данных на сервер, обработка на сервере и отдача клиенту. И тут в дело включается весь стек tcp/ip, эффективность работы сети / ос / сервера. И числа будут куда более скромные. Но это будут числа, имеющие смысл.
не согласен. то что вы считаете RPS это PING который зависит от местоположения сервера и клиента и времени работы сервера
Это именно RPS. Поскольку без учета задержек на сетевом стеке замеры не имеют смысла. Если вы сделаете обработку запроса в 0 наносек, то по вашей экстраполяции у вас будет бесконечное кол-во rps, что полный бред ))) Но на самом деле, поскольку сетевой стек (не сеть, а именно работа с tcp/ip на уровне ос) вносит задержки, rps упрется в потолок.
И еще одно важное замечание. На кол-во rps влияет кол-во подключений. К примеру, при 100 пользователях сервер может держать 1000rps, но при 1000 пользователях может "задыхаться" и опустится до 100rps. И при нагруз тесте как раз строят график: зависимость rps от параллельных юзеров.
вы начали с того что RPS называет кто как хочет. И меня принуждаете назвать как хотите вы. Мой смысл измерить скорость работы механики. PING у меня измеряет другой показатель. Пропускную способность канала - третий.
То что вы описываете про пользователей не RPS, а FPS (который у сервера свой, по умолчанию 1000 максимальный) он зависит от количества ядер, количества запуска механик игроков которые тратят время включенное в RPS.
Я не обязан назвать вашим языком то , над чем работаю сам. А то над чем работаю - не скрывая расписываю
Я не принуждаю называть вещи "моими" именами. Я прошу называть вещи общепринятыми в it терминами: https://en.wikipedia.org/wiki/Web_server#requests_per_second
ping - это время потраченное на отправку и прием ip-пакета (icmp/tcp/udp), работа сервера тут вообще не учитывается.
rps - это в общем случае: время на отправку/прием пакетов + время на сетевой стек ос + время на разбор запроса сервером + время работы условного обработчика.
то что вы измеряете - это время работы обработчика. это время бузусловно важно, но не показывает эффективности веб-сервера в целом.
время на отправку/прием пакетов нам не изменить, оно у каждого клиента будет свое, но в нагрузочном тесте мы его можем минимизировать, делая замеры с соседнего сервера в дц.
а вот на время сетевого стека / время разбора сервером мы можем повлиять, делая тонкую настройку системы и веб-сервера.
FPS - это частота отрисовки кадров (frames) на клиенте, как это применимо к сети не знаю.
вас не смущает что вы все это время думаете что у меня веб сервер ? Я не хочу с вами спорить и видно эта статья не для вас - просто пройдите мимо
веб-сервер это общее понятие, в т.ч. сервер работающий по вебсокетам, и в статьях описывался именно такой подход.
все верно, статья не для меня, но комментариями я хочу дать вам направление для развития. по статьям и сайту проекта видно, что вы варитесь в собственном соку и нет обратной связи по вашей работе.
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
Казнить нельзя помиловать. Очень сложно читать) Особенно без знаков препинания) Не ругаю, если что, но сетую)
Если у вас есть свой вариант как вышеописанный функционал обозначит какими терминами указать мне на странице тестов - welcome
Глянул по ссылке:
RPS среды выполнения кода PHP
~1.500.000 запросов в секунду т.к. и WebSocket и игровой сервер написаны на одном языке программирования PHP.
Как может WebSocket быть написан на PHP? Как могут быть запросы от протокола к серверу PHP? Какой это вообще имеет смысл без конфигураций железа, полезной нагрузки, сложности алгоритмов? Количества клиентов, длительность нагрузки, ширина канала?
И при чем тут вообще язык программирования? Если для расшифровки SHA256 и клиент и сервак будет на JS - тоже будет 1,5 лямов в секунду? А на если сервак на RUST - то уже меньше?
Вот определение того, что такое RPS. Это метрика веб-сервера.
number of requests per second (RPS, similar to QPS, depending on HTTP version and configuration, type of HTTP requests and other operating conditions);
Т.е. количество запросов в секунду. Запросов от источника к получателю. Для онлайн приложений - от клиента к серверу. Тут не нужно фантазировать и придумывать свои термины - всё уже придумано и применяется на практике.
запускается внутри цикла еще один цикл который обрабатывает каждое живое существо и в нем еще один цикл который обрабатывает все навешанные механики на конкретное существо
В теории если скорость самой быстрой игровой механики 0.001 мс то игровой сервер может обработать 1.000.000 этих механик в секунду и можно сказать что именно игрового сервера RPS равен 1М
Нет. Есть такая вещь, как сложность алгоритмов. Если у нас цикл в цикле - то это не линейная сложность, а геометрическая. Прежде чем обсуждать метрики - полезно знать теорию. Может, я что-то не так понял, но судя по скриншотам - с клиента на сервак гоняется JSON через WebSocket с полным содержанием всех объектов на сервере. И RPS как раз и нужен, для понимания того, как поведет себя система при высоких нагрузках, например, в 100, 200 одновременных клиентов.
Количество обработок "механик", чтобы это не значило - нельзя назвать запросом. "Механики" разнесены по микросервисам? Или на каждый обработчик "механики" отдельный инстанс/контейнер? Если это не горизонтально масштабируемая микросервисная архитектура - то это не запросы (requests).
Я не ругаю, если что) Вношу ясность. И сетую на качество письма...
"...Websocket и игровой сервер" - написано на странице. А сервер может быть написан на php (открывать сокет, слушать порт), по ссылке есть публичные тесты приложений
В своем проекте я волен называть вещи как они мне кажутся верным , расшифровывая что я имею в виду - не докторскую защищаю а делаю игру , что бы зацикливаться на научнрй терминалогии.
Вы спросили метрики - я вам их ответил. Сейчас дискутируете не над показателями, а над тем как я из называю
Вы спросили метрики - я вам их ответил. Сейчас дискутируете не над показателями, а над тем как я из называю
Я ничего не спрашивал. Наткнулся на комменты @vasyakolobok77 вот и написал.
В своем проекте я волен называть вещи как они мне кажутся верным что бы зацикливаться на научнрй терминалогии.
Это не научная, а профессиональная. В разговоре с самим собой - хоть сервер называйте "бибика", а статусы HTTP - "кака", но не при общении с профессиональным айтишником.
Дабы не мультипостить - отвечу тут.
И RPS это не имя собственное (во всяком случае в моем проекте)
Это устойчивый термин. Все равно что сказать - я вешу 1 кг. Кг - это кило грамм, но не ваш научный, а какой я сам придумал. Мой кило грамм - это сколько я вешу, а не ваша научная... Ну ок, только вот кому нахрен нужен вес в этих килограммах?
Вы же не предложили никакой конкретики , кроме переименования в "сложность алгоритма" которая выражается в O(n) , когда в моих метриках я хочу показать скорость в мс. на конкретном железе .
Я не предлагал ничего переименовывать. Еще раз:
В теории если скорость самой быстрой игровой механики 0.001 мс то игровой сервер может обработать 1.000.000 этих механик в секунду и можно сказать что именно игрового сервера RPS равен 1М
Допустим, некая обработка, например - проверка пересечения персонажей на поле занимает 0.001мс. Тогда, если персонаж всего 1 то 0.001. Если персонажей - 2, то тоже 0.001мс. Если 3 - то, 002мс, если 4 - то проверка пересечения 1 с 2, с 3, с 4, 2 с 3, 2 с 4, 3 с 4 - уже 0.006мс. И т.д. по формулам комбинаторики. В итоге сложность - О(n!). Для 10 будет 
, без учета доп расходов, вроде повышенной нагрузки на канал, систему, память/сборка мусора и т.д. А нагрузка на канал - тоже геометрически растет. Это и есть временная сложность алгоритмов. А скорость ответа (т.е. RPS) - это уже другое.
1ый курс программирования, это основы. Все равно, что называть себя врачом и не знать, что такое болезнь, уколы и таблетки. В общем, если за плечами только онлайн школа программирования или пара классов - то лучше сразу об этом писать.
И RPS это не имя собственное (во всяком случае в моем проекте), а сокращение Requests Per Second, что в переводе означает Запросов В Секунду
Там где у меня запросы (к игровому серверу, с websocket серверу и в т.ч. к Http серверу) использую это сокращение
Вы же не предложили никакой конкретики , кроме переименования в "сложность алгоритма" которая выражается в O(n) , когда в моих метриках я хочу показать скорость в мс. на конкретном железе .
Так или иначе если я буду сидеть над идеальными названиями , то разработка не закончится никогда.
скорость обработки именно запросов зависит от пропускной способности сервера.
если вас интересует пропускная способность канала websocket на этом проекте то она расписана в статье https://habr.com/ru/articles/670296/
и как вы сами заметили каждый под RPS что то свое кроет - вы там кроете ping который у всех разных и ничего о скорости именно сервера не говорит
Это не время запроса, а время отклика. Т.е. время, между получением запроса и началом ответа.
Создание сервера для онлайн ММО игр на PHP ч. 9 — Игровые серверные механики