Из того, что я вижу, если событие в узле принимает «длительное время» для отправки, узел создает какую-то «очередь событий», и они запускаются как можно скорее, поодиночке.Сколько событий может содержать очередь node.js?
Как долго может стоять эта очередь?
Хотя это может показаться простым вопросом, это на самом деле довольно сложная проблема; к сожалению, нет простого числа, которое может вам дать любой человек.
Во-первых: настенное время на самом деле не играет никакой роли. Все события отправляются одинаково, независимо от того, принимаете ли вы «долгое время». Другими словами, все события проходят через «очередь».
Во-вторых: единой очереди нет. Есть много мест, где различные события могут быть отправлены в JS. (Далее предполагается, что вы know what a tick is.)
process.nextTick(). Они вызываются в конце текущего тика, пока очередная очередь очереди не будет пустой.setImmediate(). Они вызывают в начале следующего тика. (Это означает, что nextTick задачи могут добавить вещи к текущему клещу на неопределенное время, предотвращая другие операции происходили тогда setImmediate задача может добавлять только вещи в очередь на следующий такт.)epoll/kqueue/IOCP на Linux/Mac/Windows соответственно. Когда ОС уведомляет libuv о том, что I/O произошел, он, в свою очередь, вызывает соответствующий обработчик в JS.Указанный тик цикла событий может обрабатывать ноль или более событий ввода-вывода; если тик занимает много времени, события ввода-вывода будут стоять в очереди в операционной системе очереди.Поскольку существует много мест, где работа может быть поставлена в очередь, it is not easy to answer "how many items are currently queued", а тем более абсолютный предел этих очередей. По сути, жесткий предел для размера ваших очередей задач - это оперативная память.
На практике, ваше приложение будет:
... задолго до того, как размер любой очереди становится проблематичным.
Если вам просто интересно, может ли представлять интерес ваше приложение под большой нагрузкой, то это может вызвать интерес к каждому типу цикла событий, чтобы определить, тратит ли ваше приложение необычное количество времени на обработку каждый тик (что может указывать на то, что очереди задач очень велики).
Обработчики для конкретного события называются синхронно (в порядке их добавления) , как только событие испускается, они не задерживаются вообще.
Общее количество обработчиков событий ограничено только v8 и/или объемом доступной ОЗУ.
, если достигнуто ограничение лимита, будет ли приостановка узла приостановкой дополнительных событий до тех пор, пока больше памяти не освободится или VM просто не закончится? Я пытаюсь понять, является ли это причиной моей проблемы с OOM (http://stackoverflow.com/questions/36492268/nodejs-running-out-of-memory-processing-csv-files/36493158?noredirect= 1 # комментарий60612338_36493158) –
@DmitryB. Если v8 не может выделить больше памяти и попытки GC достаточно пространства не удастся, он умрет, как и большинство других программ. – mscdex
Я полагаю, что вы говорите об операциях, которые могут пройти неопределенное количество времени, таких как запрос HTTP или доступ к файловой системе.
Узел дает вам метод для выполнения этих операций в асинхронном режиме, что означает, что вы можете указать узлу или библиотеке сторонних разработчиков для запуска операции, а затем вызвать некоторый код (определяемую вами функцию), чтобы сообщить вам когда операция завершена. Это можно сделать через прослушиватели событий или функции обратного вызова, оба из которых имеют свои собственные ограничения.
С прослушивателями событий максимальное количество слушателей, которое вы можете получить, зависит от максимального размера массива вашей среды. В случае node.js механизм javascript равен v8, но согласно this post максимальный уровень, установленный 5-м стандартом ECMA в ~ 4 миллиарда элементов, который является пределом, которого вы никогда не должны преодолевать.
С обратными вызовами ограничение, которое у вас есть, - это максимальный размер стека вызовов, что означает, насколько ваши функции могут звонить друг другу. Например, вы можете иметь обратный вызов, вызывающий обратный вызов, вызывающий обратный вызов, вызывающий другой обратный вызов и т. Д. Размер стека вызовов определяет, как могут быть обратные вызовы, вызывающие обратные вызовы, которые вы можете иметь. Обратите внимание, что размер стека вызовов может быть ограничением с помощью прослушивателей событий, а также, по сути, это обратные вызовы, которые могут выполняться несколько раз.
И это ограничения с каждым.
Re прослушиватели событий, размер массива - это ограничение на количество функций обратного вызова слушателя *, прослушивание событий, а не ограничение на размер событий, которые будут отправляться в очередь. Кроме того, ограничения стека вызовов можно обрабатывать с помощью 'setImmediate' /' process.nextTick'. – josh3736
Насколько мне известно, нет очереди на события, ожидающие отправки. Когда вызывается 'dispatchEvent' или' emit' или аналогичная функция, все слушатели этого события вызываются перед возвратом 'dispatchEvent'. Конечно, вы можете иметь вложенную диспетчеризацию событий, когда слушатель событий может отправить другое событие, но пока не происходит «очереди». Хотя это мой опыт работы с событиями. Может быть какой-то механизм, который использует узел для сброса стека вызовов, который использует очередь? Но как я описал это, как правило, работают события. – BAM5
Кроме того, да, ограничение размера массива - это ограничение на количество слушателей, которое вы можете иметь для одного типа событий. – BAM5
Я не думаю, что есть предел, но ваша оперативная память. – Bergi
Я считаю, что события на самом деле всегда поставлены в очередь. – jcaron
Я не думаю, что это так, как очередь событий обрабатывается –