Express.js с Node.js, несколько клиентов

Чтобы явно ответить на этот вопрос, я думаю, требуется более глубокое понимание цикла асинхронных событий Node.js.

JavaScript является однопоточным, и использование этого асинхронного цикла событий позволяет Node.js выполнять неблокирующие операции ввода-вывода в этом единственном потоке.

Это достигается путем передачи операций в ядро, когда это необходимо (например, при большом количестве запросов или операций ввода-вывода), а затем получения результата в более позднее время в цикле событий, в фаза «опроса».

Чтобы дать дополнительные пояснения, я включил диаграмму, представленную в документации Node.js:

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

Более подробно об этих этапах можно прочитать по адресу: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

Вкратце:

• таймеры: здесь будут выполняться запланированные обратные вызовы и все, что установлено в таймерах, например setInterval () или setTimeout (). Причина, по которой это первое, заключается в том, что это просто гарантия того, что указанное количество времени - это минимальное количество времени, которое может потребоваться для их срабатывания. Это время также дополняется временем завершения циклов цикла событий. Наличие их здесь - это способ обеспечить их максимальную точность в соответствии с тем, что разработчик указал в функциях интервала или тайм-аута.
• ожидающие обратные вызовы: выполняет обратные вызовы ввода-вывода, отложенные до следующей итерации цикла. Если максимальное количество обратных вызовов достигается в любом цикле событий, остальные обратные вызовы, которые необходимо выполнить, откладываются до следующего цикла (что может быть выполнено вручную с помощью process.nextTick ()), поэтому - после таймеров они должны выполняться следующий
• холостой ход: используется только для внутреннего использования. Если в цикле событий нечего обрабатывать, цикл перестанет откладывать что-либо ядру до тех пор, пока это не понадобится.
• подготовить: используется только для внутреннего использования. Готовится к следующему циклу цикла событий, если потребуется один или несколько
• опрос: получение новых событий ввода / вывода; выполнять обратные вызовы, связанные с вводом-выводом (почти все с исключение обратных вызовов закрытия, запланированных таймерами и setImmediate ()); узел будет заблокирован здесь, когда это необходимо. Эта фаза опроса позволяет продолжить все, что было отложено.
• check: здесь вызываются обратные вызовы setImmediate ()
• закрытые обратные вызовы: некоторые закрытые обратные вызовы, например socket.on ('close', ...) и другие события 'close' вызываются здесь

Опять же, большая часть этого взята из документации Node.js, но я немного подробно остановился на некоторых деталях, чтобы обеспечить некоторое понимание в этом контексте.

В вашем случае операции с вашей базой данных не будут «блокировать» других пользователей, им просто нужно будет ждать, пока их обратные вызовы не будут обработаны через цикл. Если бы выполнялось много операций одновременно, большее количество операций было бы выгружено в ядро, а затем загружено как можно скорее, что может вызвать небольшую дополнительную задержку (1).

Еще один хороший рисунок, который поможет визуализировать этот процесс, взят из этой статьи: https://webapplog.com/you-dont-know-node/

На стороне примечания -

Есть места, где цикл обработки событий Node.js является хорошим решением, и другие места, где более надежное многопоточное решение может быть лучшим подходом. Никогда не бывает плохой идеей обязательно провести исследование, необходимое для разумного принятия решения, связанного со спецификой вашего проекта.

(1) Есть несколько статей о различиях в производительности, ожидаемой задержке при больших нагрузках на сеть и различных решениях этой проблемы, которые находятся в поиске в Google.

Надеюсь, это поможет!