Мне в руки даже железка попадала на 99% такая же, которая все эти бенчи выполняет (только сетевушка была не на 40, а на 25). И даже там я не стал разворачивать полноценный репо FrameworkBenchmarks. Просто отдельно потестил на нём несколько движков.
Вот гляньте на показатели fastwsgi - он в топе в каждом типе бенча. А я просто при формировании PR указал такие же параметры, как и у других движков.
Ну зачем же. Я у себя локально этот бенч и не разворачивал. Просто добавил PR для fastwsgi и blacksheep - эти движки теперь в репо.
Сначала нужно подождать добавления PR (обычно не более 7 дней). Затем дождаться окончания текущей задачи бенча и след. задачи, в которую уже обязан попасть ваш PR/commit.
ASGI-серверы значительно превосходят WSGI по производительности
Вывод неверный. ASGI-серверы быстрее при асинхронном выполнении запроса (БД и т.п.). В полностью синхронных запросах WSGI протокол быстрее, т.к. проектировали ASGI протокол "странные" люди. Вот пруфы:
Запросы, которые просто формируют из статики JSON-текст
Запросы с обращением к БД
Можно заметить, что на второй картинке вообще нету WSGI-движков, т.к. wsgi просто бесполезен при запросах к БД.
Granian показывает лучшие результаты как по скорости, так и по потреблению памяти
Для этого вывода нужна выборка по более. А у вас она маленькая.
Например, в спецификации описано, как работает конвейеризация HTTP, но, если вы попробуете задействовать эту фичу «на местности», то сами напрашиваетесь на проблемы и… всё окончится грустно.
Верно подмечено. Я изучал имплементацию pipelining'а на примере некоторых топовых фреймворков из списка TechEmpower FrameworkBenchmarks. Разрабы делают реализацию просто в лоб и тупо. К примеру, если скорость приёма сервера больше, чем его отдача, то просто пожирается память на выделение всё новых буферов в памяти.
Я же в проекте fastwsgi сделал эту часть HTTP-сервера по умному. Т.е. сервер умеет притормаживать чтение входящих запросов, в зависимости от состояния части, отвечающей за отправку данных.
---------------
Ну и ссылочка на топик, где я сетую на то, что в Python-лидерах находится "поделка", которая просто базовые требования TCP-сервера не соблюдает, не то что HTTP:
я уверен, что когда докладчик с горящими глазами, и дрожащим голосом, рассказывает про ужасы и показывает что мол вот смотрите че может быть когда разработчик не понимает что он делает, а фреймфорк не читает мысли того самого разработчика и вот ужас, мы накрутили процентов... ну да, я уверен что все проголосуют что уязвимость....
в копиляторе С кстати дохера таких, например, когда пытаешься прочитать непроинициилизированный поинтер, а компилятор ничего с этой попыткой не делает
Мде. Походу челы ваще не понимают как нативный код работает, коли ждут от Сишечки проверок.
Я вот тоже недавно решил сделать open source утилиту для вывода инфы о железе и его параметрах. Решил делать именно на питоне, т.к. порог вхождения контрибьютеров будет поменьше. Да и не нужен нативный код для таких задач.
Для работы с оборудованием использую не устаревший winring0, а cpuidsdk(cpuz.sys), на который антивири не ругаются.
Вот и вспомнилось сразу, как пришлось костыль делать в проекте FastWSGI. На самом деле при написании кода под WSGI интерфейс возникло очень много вопросов к авторам сия придумки. Довольно затратны процессы сериализации/десериализации. Сразу вспоминается HTTP-протокол: HTTP 1.x придумали псевдо-программисты, а HTTP 2.x (и далее) - настоящие программисты.
Так вот, одной из проблем WSGI является использование BytesIO. И добавить в поток байтиков можно только Py-объект (для этого используется функция _io_BytesIO_write).
А функцию для добавления сразу "сырого" куска из памяти (char * bytes) в CPython не завезли.
Среди китайцев есть ptpt52, который довольно активно коммитит в офиц. репозиторий OpenWrt. И у него есть и свой форк OpenWrt: https://downloads.x-wrt.com/rom/ Сборки X-WRT отличаются от офиц. сборок.
У меня как то язык не повернётся назвать это "сборкой китайского васяна".
На данный момент - это лучший вариант... диапазон цен 4500-5500р
про RT-AX53U (mt7621A):
Находится в том же диапазоне цен, но железо чуть слабее. У Redmi выше тактовая частота, а значит, он в теории будет лучше справляться с шифрованием данных. Для роутера в наших реалиях - это в первую очередь туннели OpenVPN, Wireguard итд. По бенчмаркам MT7622B лучше почти в два раза
Видимо вы неверный вывод сделали из статьи 2023 года.
Появление в 2023 году устройств с mt7622 и mt7981b изменило расклад. Старый чип mt7621 явно стал не актуален. Да и в 2024 году почти каждому стал нужен шифрованный туннель в роутере.
Среди Кинетиков только сейчас появились модели на mt7981b (в 2023 году там правил балом mt7621 и его клоны).
Наверное стоило упомянуть, что у ASUS TUF-AX6000 есть полная копия в виде ASUS TX-AX6000 (просто другой корпус, продаётся только на китайском рынке).На озоне его продавали зимой за 13500руб.
ASUS TX-AX6000 занял в одном из китайских тестов первое место по соотношению цена/производительность:
Есть галактики, расстояние до которых превышает 13 млрд. лет.
Расширение пространства не ограничивается скоростью света. Из-за этого мы и можем только наблюдать за галактиками только в определённой сфере. Всё остальное за этой сферой мы не увидим никогда.
Мне в руки даже железка попадала на 99% такая же, которая все эти бенчи выполняет (только сетевушка была не на 40, а на 25). И даже там я не стал разворачивать полноценный репо FrameworkBenchmarks. Просто отдельно потестил на нём несколько движков.
Вот гляньте на показатели fastwsgi - он в топе в каждом типе бенча. А я просто при формировании PR указал такие же параметры, как и у других движков.
Я больше доверяю вот этой табличке:
Ссылка на первоисточник: https://www.techempower.com/benchmarks/#section=test&runid=3ab00ae1-17aa-44e6-ae83-137d797d0817&test=json&l=zik0zj-cn2&w=oedrsv-v2qiv3-zik0zj-zik0tr&a=2
Ну зачем же. Я у себя локально этот бенч и не разворачивал. Просто добавил PR для fastwsgi и blacksheep - эти движки теперь в репо.
Сначала нужно подождать добавления PR (обычно не более 7 дней). Затем дождаться окончания текущей задачи бенча и след. задачи, в которую уже обязан попасть ваш PR/commit.
Отслеживать можно тут: https://tfb-status.techempower.com/
Условия одинаковые. Настраивают сами авторы движков (в редких случаях умельцы).
Автор granian недавно сделал изменение:
https://github.com/TechEmpower/FrameworkBenchmarks/commit/3c18f02c4c6e1a323b98bd78c5258297dadc4b9a
Поэтому: либо 2, либо 4
Вот: https://github.com/TechEmpower/FrameworkBenchmarks/blob/ea7463af6a1394193e0039eec1545f70301d17d7/frameworks/Python/granian/run.py#L10-L14
Потоков там 56 (пруф: https://github.com/TechEmpower/FrameworkBenchmarks/issues/8736#issuecomment-1973835104 )
Вывод неверный.
ASGI-серверы быстрее при асинхронном выполнении запроса (БД и т.п.).
В полностью синхронных запросах WSGI протокол быстрее, т.к. проектировали ASGI протокол "странные" люди.
Вот пруфы:
Можно заметить, что на второй картинке вообще нету WSGI-движков, т.к. wsgi просто бесполезен при запросах к БД.
Для этого вывода нужна выборка по более. А у вас она маленькая.
Лучшие результаты смотрите тут: https://www.techempower.com/benchmarks/#section=test&runid=3ab00ae1-17aa-44e6-ae83-137d797d0817&l=zik0zj-cn2
У вас какие-то странные результаты тестирования. Почти всегда у ASGI-серверов задержка больше, чем у WSGI.
И это подтверждается вот этой картинкой:
Явно видно, что все ASGI проигрывают WSGI.
Примечание: именно ради низких задержек я юзаю fastwsgi (и почти весь его переписал)
Django очень медленный:
https://www.techempower.com/benchmarks/#section=test&runid=e8b36ecc-d623-48bb-936d-d043e9db2c13&l=zik0zj-cn2&a=2&test=json
А бенч вот тут стоит ожидать?
https://www.techempower.com/benchmarks/
Разбирался. Всё так и есть. Даже было время, когда на работе 99% такую же железку взял и установил там некоторые бенчи и лично проверил:
https://github.com/TechEmpower/FrameworkBenchmarks/issues/7402#issuecomment-1482918369
Получил довольно близкие цифры.
Раньше у них стояли 10Gbit сетевухи, а теперь уже 40Gbit. Мне на работе удалось проверить только 10Gbit и 25Gbit.
Вот точный конфиг: https://github.com/TechEmpower/FrameworkBenchmarks/issues/8736#issuecomment-1973835104
Верно подмечено. Я изучал имплементацию pipelining'а на примере некоторых топовых фреймворков из списка TechEmpower FrameworkBenchmarks. Разрабы делают реализацию просто в лоб и тупо. К примеру, если скорость приёма сервера больше, чем его отдача, то просто пожирается память на выделение всё новых буферов в памяти.
Вот тут я немного возмущался: https://github.com/TechEmpower/FrameworkBenchmarks/discussions/8048
Я же в проекте fastwsgi сделал эту часть HTTP-сервера по умному. Т.е. сервер умеет притормаживать чтение входящих запросов, в зависимости от состояния части, отвечающей за отправку данных.
---------------
Ну и ссылочка на топик, где я сетую на то, что в Python-лидерах находится "поделка", которая просто базовые требования TCP-сервера не соблюдает, не то что HTTP:
https://github.com/TechEmpower/FrameworkBenchmarks/issues/9055
Вот такие чудеса на виражах.
Мде. Походу челы ваще не понимают как нативный код работает, коли ждут от Сишечки проверок.
Я вот тоже недавно решил сделать open source утилиту для вывода инфы о железе и его параметрах. Решил делать именно на питоне, т.к. порог вхождения контрибьютеров будет поменьше. Да и не нужен нативный код для таких задач.
Для работы с оборудованием использую не устаревший winring0, а cpuidsdk(cpuz.sys), на который антивири не ругаются.
Пока основное направление - тайминги DDR5.
Поиск сорцов по названию: pyhwinfo
Что за ересь то? У вас в примере изначально указано число, которое не может хранится во float8 без потери точности. Сложение тут вообще не причём.
Эта статья уровня школьных рефератов. Да ещё 4 плюсика уже есть... за что?
Знакомый код.
Вот и вспомнилось сразу, как пришлось костыль делать в проекте FastWSGI. На самом деле при написании кода под WSGI интерфейс возникло очень много вопросов к авторам сия придумки. Довольно затратны процессы сериализации/десериализации.
Сразу вспоминается HTTP-протокол: HTTP 1.x придумали псевдо-программисты, а HTTP 2.x (и далее) - настоящие программисты.
Так вот, одной из проблем WSGI является использование BytesIO. И добавить в поток байтиков можно только Py-объект (для этого используется функция
_io_BytesIO_write).А функцию для добавления сразу "сырого" куска из памяти (
char * bytes) в CPython не завезли.И вот пришлось самому конструировать этот механизм вот таким образом: https://github.com/jamesroberts/fastwsgi/blob/5572bb31b859d690be225707b9e7e25af397544b/fastwsgi/pyhacks.c#L148-L154
Хотя много где в CPython есть методы, которые позволяют передавать им "сырые" куски памяти через
char *, но вот вbytesio.cтакие забыли завести.Вот с чем может быть связана такая забывчивость?
И можно ли было обойтись без костылей, реализованных в pyhacks.c ?
PS.: нагуглил тут похожую проблему и на чистом питоне https://stackoverflow.com/questions/78399639/how-to-use-io-bytesio-in-python-to-write-to-an-existing-buffer
Среди китайцев есть ptpt52, который довольно активно коммитит в офиц. репозиторий OpenWrt.
И у него есть и свой форк OpenWrt: https://downloads.x-wrt.com/rom/
Сборки X-WRT отличаются от офиц. сборок.
У меня как то язык не повернётся назвать это "сборкой китайского васяна".
Так и в статье 2023 года @itdog писал такое:
про AX6S (mt7622B):
про RT-AX53U (mt7621A):
Видимо вы неверный вывод сделали из статьи 2023 года.
Появление в 2023 году устройств с mt7622 и mt7981b изменило расклад. Старый чип mt7621 явно стал не актуален.
Да и в 2024 году почти каждому стал нужен шифрованный туннель в роутере.
Среди Кинетиков только сейчас появились модели на mt7981b (в 2023 году там правил балом mt7621 и его клоны).
Наверное стоило упомянуть, что у ASUS TUF-AX6000 есть полная копия в виде ASUS TX-AX6000 (просто другой корпус, продаётся только на китайском рынке).На озоне его продавали зимой за 13500руб.
ASUS TX-AX6000 занял в одном из китайских тестов первое место по соотношению цена/производительность:
Источник: https://youtu.be/Z72ooqxaYb8?t=506
Расширение пространства не ограничивается скоростью света. Из-за этого мы и можем только наблюдать за галактиками только в определённой сфере. Всё остальное за этой сферой мы не увидим никогда.