Node.js - Максимальное время, рекомендуемое в синхронных операциях

Question

Синхронный аддон блокирует цикл событий Node.js. Но, возможно, существует «стандартный» предел, допустимый для блокировки цикла события.

var results = addon.my_function(parameters); //consumes 2ms 

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

Answer 1

Как вы знаете, узел node.js имеет модель параллелизма, которая учитывает только параллелизм связанных с IO задач. Любая серийная задача, которая не разбивается, приостанавливает цикл событий для этой продолжительности. Можно реализовать подпрограммы, чтобы разбить эту задачу, но она только устанавливает специфические парадигмы. Если вы выполняете одну операцию, которая займет много времени, тогда вы должны изучить параллелизм. Если вы обрабатываете набор данных, например массив или файл за строкой, вы можете реализовать рекурсивную функцию для замены цикла, и когда вы рекурсируете вместо прямого вызова вашей функции, вы можете отложить ее с помощью setTimeout, чтобы вы могли возобновить ваш eventloop, чтобы не останавливать его слишком долго (до тех пор, пока не произойдет тайм-аут).

Я не могу дать вам точное время, когда синхронная задача будет считаться «слишком длинной». Это действительно зависит. Слишком много факторов. Как часто эта задача происходит, действительно имеет значение.

Есть несколько подходов к обработке этих видов задач:

1. разбивая серийную задачу. Установка таймаута для разбивки частей задачи в вашем цикле событий, как я уже упоминал ранее. Хотя, если у вас достаточно этих задач, это все равно может вызвать проблему.
2. Рассмотрим параллелизм. Параллелизм - неплохая концепция для удаления последовательной задачи из цикла событий, но только если это событие не происходит часто. У параллелизма много накладных расходов.
3. Отгрузка работнику. Отодвиньте это событие к работнику или группе работников. Это очень распространено, и единственным недостатком является небольшое увеличение эксплуатационных расходов (возможно), и если вы не будете осторожны, вы можете создать то, что трудно поддерживать (многие небольшие системы без центрального соглашения).
4. Очередь и ограничение параллелизма. Если задача короткая, но частая, вы можете просто поставить их в очередь и убедиться, что только некоторые из них обрабатываются одновременно, чтобы ваш eventloop не был заблокирован слишком долго.

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

Если ваша задача связана с IO, работа по ее изменению в асинхронном режиме должна быть тривиальной, поскольку nodejs построена с нуля с помощью этой парадигмы. Это плохая практика, если вы не используете асинхронные методы, когда это возможно. Хотя это связано только с IO. Если вы задача не чтение/запись данных в/из какого-то источника, асинхронные методы ничего не сделают для вас.