Комментарии 12
Моей целью было протестировать производительность и поведение сервера в обыденных для веб приложения условиях.
Вопрос поднят правильный. Но вот выбор задач для сравнения спорный:
вычисление ряда Фибоначчи, что, по моему мнению, не раскрывает всей сути сравнения
Но ведь выдача копеечных константных джсонов тоже не раскрывает. И отдача статики - не типичная задача для подопытных.
Чем хорош Fastify так это валидацией входящих джсонов по схемам (JSON Schema), благодаря либе ajv. Схемы создаются один раз при старте, и потом в каждом запросе просто и быстро применяются. Вот добавить бы в тест такое.
Второе, что не учтено - обработка ошибок. Ошибки же надо обрабатывать, выводить понятное сообщение, с указанием чего в запросе не хватает. Часто в бенчмарках тестируют только заведомо успешные запросы, что далеко от жизни.
Третье - логирование. Ведь одно дело логировать как-попало, например, через синхронный console.log. Совсем другое - логировать структурно и в отдельном потоке, как это делается в Fastify через либу pino.
Здравствуйте! Да, вы правы, как я и отметил в заключении логирование, обработка ошибок и прочее не были учтены, в Fastify очень много полезных и удобных вещей, которые ускорят работу реального приложения и покажут лучшие результаты чем express, но они не затрагивались в статье, думаю раскрыть подробнее позднее
Касательно статики - целью этой мини статьи как раз таки было проверить скорость работы этих фреймворков не учитывая обработку данных, работу с валидацией, сериализацией и тд.
Спасибо большое за комментарий, в следующих статьях я буду затрагивать более углубленные темы касательно сравнения этих фреймворков.
Здесь сравнение не корректное (между Express и Fastify).
Express в функции sendFile "под капотом" использует fs.readFile(), т.е. читает файл с диска (один раз) целиком, и только после этого вызывает колбэк (когда весь файл в оперативной памяти).
В Fastify используете стримы, которые читают файл с дика (HDD, SSD) порционно, т.е. может быть много обращение к диску, а это сильно медленно. Плюс, стрим добавляет калбэк в eventloop (когда прочитал порцию данных), что тоже замедляет выполнение.
P.S. что "под капотом" у Коа, не знаю.
Хм, если так, то вы правы, сравнение не корректное, но насколько я вижу для чтения файла в express используется библиотека send, под капотом которой, опять таки, если залезть туда, видно, что вызывается именно createReadStream.
Я не углублялся в код express и библиотек, которые он использует, просто мельком глянул сейчас библиотеку, поэтому могу ошибаться, конечно
есть специальный бенчмарк фрейморков, в т.ч. на ява-скрипте https://www.techempower.com/benchmarks/#hw=ph&test=composite§ion=data-r22&l=zik0sf-cn3
Здравствуйте! Спасибо, как нибудь попробую
Я думаю было бы интереснее, если бы провели тесты для сравнения с современными nodejs фреймворками, например: h3, hattip, elysia, hono, oak. Express-у уже более 10 лет, большая часть компаний перешла на fastify. Nuxt перешел с koa на h3. Сейчас каждый новый js фреймворк хвалиться скоростью, вот только методы проверки спорные
А почему в последнем тесте для фастифай используется потоковая передача, а для конкурентов отправка файла? Возможно, в этом причина такого разброса в последнем тесте?
Здравствуйте! Да, вы правы, основная проблема заключается в использовании потоковой передачи, возможно с использованием пакета fastify-static такого разрыва бы не было, но при использовании новейших версий fastify@4.24.3 и fastify/swagger@8.12.0 пакет fastify/static не подключается, просит понижения версии fastify до 3.x., чего мне делать крайне не хотелось.
Также суть тестирования - проверить скорость работы с использованием базовой и наиболее простой конфигурации серверов, соответственно если для подключения пакета требуется понижение или повышение версий других пакетов и прочие танцы с бубном, то это уже выходит за рамки текущей статьи.
Но да, в следующих статьях я планирую проводить тестирование на более реальных проектах
Я воспользовался@fastify/static(который предоставляет метод .sendFile) и в итоге получил разницу 2x в пользу Fastify
Статья явно написана новичком и почему её залайкали - хороший вопрос
Здравствуйте! Можете прочитать комментарий выше(я понимаю, я написал его после вашего комментария, но тем не менее), где я описал по какой причине не стал использовать плагин fastify/static. Если вкратце, то использование данного плагина выходит за рамки тестирования. А если вас интересует мой опыт - 6 лет в разработке, на данный момент работаю в Европе над созданием крипто-кошелька, если интересует все резюме - напишите куда вам отправить
Гонка за скоростью: сравнение производительности ведущих фреймворков JavaScript в веб-разработке. Fastify, Express, Koa