Nestjs против простого экспресс-исполнения

Question

Я только что проверил производительность на контроллере простого гнезда, который возвращает текст по запросу get (без базы данных). И тот же простой GET-контроллер (middleware) с экспрессом.

Я использовал инструмент WRK для тестирования производительности.

И в результате простой экспресс в 2 раза быстрее, чем nestjs. Почему nestjs создает так много накладных расходов?

Answer 1

ОБНОВЛЕНИЕ - 22.09.2018

В репозиторий был добавлен каталог тестов: https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt (вы также можете запускать тесты на своем компьютере).

ОБНОВЛЕНИЕ - 24.06.2018

Гнездо v5.0.0 опоры крепятся. Интеграция Fastify + Nest даже более эффективна, чем простой (!) Экспресс.

---

В следующем списке показано, что делает Nest по сравнению с обычным экспресс-обработчиком маршрута:

• он окружает тело вашего обработчика маршрута блоками try..catch
• это делает каждый обработчик маршрута async
• это создает глобальный экспресс-маршрутизатор
• он создает отдельный маршрутизатор для каждого контроллера
• это связывает промежуточное ПО для обработки ошибок
• это связывает body-parser промежуточное ПО (оба json и продлен urlencoded)

Все перечисленные вещи отражают реальный пример (вероятно, 99,9% экспресс-приложений тоже должны это делать, это неизбежно). Это означает, что если вы хотите сравнить производительность Express и Nest, вы должны хотя бы покрыть вышеуказанные моменты. Сравнение с примером ниже:

app.get('/', (req, res, next) => res.status(200).send('Hello world'));

Несправедливо в этом случае, потому что этого недостаточно. Когда я расскажу об этих моментах, это то, что я получил (экспресс 4.16.2):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 225.67 109.97  762
Req/Sec      4560   1034.78 5335
Bytes/Sec    990 kB 226 kB  1.18 MB

46k requests in 10s, 9.8 MB read

Кроме того, Гнездо должно:

• определить, является ли результат обещанием / наблюдаемым / простым значением
• в зависимости от типа результата используйте send() или же json() (+1 условие)
• добавить 3 условия (if заявления) проверить трубы, перехватчики и охранники

Выход для Nest (4.5.8):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 297.79 55.5    593
Req/Sec      3433.2 367.84  3649
Bytes/Sec    740 kB 81.9 kB 819 kB

34k requests in 10s, 7.41 MB read

Это означает, что производительность Nest составляет около 79% (-21%). Это происходит по причинам, изложенным выше, и более того, потому что Nest совместим с Node 6.11.x, что означает, что он не может использовать async / await под капотом - он должен использовать генераторы.

Какой вывод следует сделать на основе этой статистики? Нет, потому что мы не привыкли создавать приложения, которые возвращают только простые строки без каких-либо асинхронных вещей. Сравнения с Hello world ничего не значит, это всего лишь лакомый кусочек:)

PS. я использовал autocannon библиотека https://github.com/mcollina/autocannon

autocannon -c 1024 -t30 http://localhost:3000