Comments 12
Возможность описывать эндпоинты без использования макросов очень удобна.
Так у Actix-web тоже можно без макросов их задавать, через билдер.
Может плохо помню, но когда несколько лет назад смотрел доки актикса, то он очень плохо объяснял свою макросную магию. Там емнип доки вообще были 5 страничным «обмазываете макросом майн, потом обработчики, и оно магически связывается». Разумеется, чуть в сторону и вся магия ломается - ни обработчик в отдельный файл вынести, ни поменять возвращаемый тип. Да, можно поспрашивать всё у сообщества (или самому развернуть маркросы?), но нафиг такую мороку.
собственно, это можно наблюдать на тестах timed и bcrypt - разрыв между всеми тремя фреймворками становится почти незаметным
Собственно, это может означать простую вещь - что вы меряете что-то не то?
Я мерию накладные расходы фреймворков. При росте константной задержки (вызванной вычислениями или банальным sleep - этот код общий для всех трёх тестов) доля оверхеда в общих числах уменьшается. Разница между 7 и 12 мс (= 5 мс) может быть ощутима. Разница между 505 мс и 501 мс (= 4 мс) уже вряд ли будет кого-то волновать. Она не исчезает в абсолютных числах, но исчезает в относительных.
Так я не говорю что вы прямо неправильно измеряли, а скорее что может быть и надо отображать чуть иначе? По сути, вам же только накладные расходы и интересны. Ну так, условно - померять, сколько времени займут одни только вычисления, и сравнить с вычислениями + REST?
Для sleep, думаю, его можно считать равным 20 мс, как в самом sleep и написано. Для bcrypt действительно можно было бы померить.
По идее важно учесть количество рабочих тредов в этом случае, потому что, очевидно, 1 bcrypt и 10 bcrypt в разных тредах будут выполняться разное время (даже если ядер CPU больше 10, есть, например, тепловой троттлинг, который общий на всех).
Ну, в случаях многозадачности/многопоточности вообще очень сложно мерять. Т.е. самый простой вариант - вы задачу решили быстрее, но ресурсов в форме ядра*часы или гигабайты*часы потребили больше. И хорошо ли это, в общем случае не очевидно. Потому что эти измерения - они все сделаны в рамках одного приложения, если же на машине приложений больше одного - все становится сильно веселее.
Так попробовали бы какой-нибудь профайлер подрубить и посмотреть, что фреймворки практически и не добавляют расходов. Основной жёр почти наверняка придётся на сериализацию-десериализацию в JSON. Поэтому согласен с предыдущим оратором, что вы определённо меряете что-то не то. Эксепримента ради верните plain text и замерьте заново.
А что насчёт других фреймворков?
Рекомендую попробовать делать такие bench c https://github.com/hatoo/oha
P.S. Интересно ещё было бы посмотреть результаты с mTLS.
Принимает параметр в JSON, хеширует его алгоритмом bcrypt с параметром cost=10, возвращает результат в JSON
Вот так очень сильно не советую делать, это блокирует целый тред, что производительность в ноль снижает, в таких случаях нужно выносить тяжелые вычисления в отдельный тред, ну например так.
use tokio::task;
let result = task::block_in_place(|| {
// do some compute-heavy work or call synchronous code
"blocking completed"
});
assert_eq!(result, "blocking completed");Тут можно больше про это почитать
Не хватает второго теста запущенного сервиса, чтобы видеть расход памяти.
То что actix в пике скушал столько же сколько победитель, никак не говорит о его ущербности.
Тест производительности Web-фреймворков для Rust