То есть если у меня будет скажем 10 приложений, то какникрути будет создано 70 процессов? А если у меня допустим процесс ещё и форкается по 10 раз то 700 процессов? )))

Или потоков?

htop показывает что у каждой этой строки свой уникальный pid я предполагаю что это процесс.

Добрый день. Может ли кто-то подсказать один момент. Мне нужно вычислять время исполнения асинхронной функции в ноде, но я ведь правильно понимаю, что при банальном использовании таймера в начале и после вызова будет иметь место искажения времени за счет того. что в Event Loop у нас пачками операции идут и время выполнения всех колбэков в той же итерации, что и мой функция тоже войдет в общее время работы моей функции? Есть ли какие-то способы обойти это, если я правильно рассуждаю?

Тут про таймеры высокого разрешения и пример кода https://youtu.be/sanq2X7Re8o

Спасибо, я смотрел эти видео ранее. Но я не увидел в коде примеров для асинхронных функций( Или плохо смотрю?

спасибо

старт таймер перед функцией, а конец внутрь функции, там где then

Ни какой разницы, время в любом месте можно засекать и сравнивать

Имеется ввиду, что время, которое ожидается в очереди колбэков в лупе ничтожно мало и им можно пренебречь?

Меня интересует именно этот момент, если конкретизировать. Как учитывать и нужно ли учитывать то время, что тратится непосредственно на ожидание того, как асинхронная операция была выполнена на уровне ОС, но еще не наступила очередь колбэка этой операции, потому что она в лупе. Там же насколько я помню есть ограничение по времени, сколько могут обрабатываться колбэки на каждом тике?

а какой от такой точности смысл? ты тестируешь код, время от начала до завершения асинхронной операции, включая ожидания, если эти ожидания сильно влияют на перфоманс, то проблема не в тестируемой функции

Время ожидания огромно. Можно принебречь всем остальным временем исполнения, в основном происходит ожидание ввода-вывода.

В ноде есть смысл изменять не время исполнения и ожидания, а пропускную способность в кол-ве запросов rps или в мб/сек.

Хм, кажется доходит потихоньку, спасибо) Я просто боялся, что если буду мерять функцию, у которой большая вложенность различных операций, как синхронных, так и асинхронных, то время, которое уходит на разбор очередей колбэков будет портить статистику, плюс лпять же помимо этого есть и таймеры и события, которые тоже отжирают понемногу.

Поэтому, измерить можно только статистику, миллион вызовов нужно сделать и разделить время на миллион.

А это точно про io? Потому что так выйдет поменять только то как хорошо, например, файловая система конкретного окружения умеет кешировать и сколько у неё для этого памяти.

А это ни как разделить не выйдет, только все целиком можно замерить

Профайлер как вариант. В случае ноды у хрома очень даже достойный. Найти что-то особо тяжеловесное с ним вполне реально.