Таймерите на Node.js са много ефективно внедрени. Тяхното изпълнение (описано в подробна статия за това как работят) може лесно да се справи с много голям брой таймери.
Те се съхраняват в двусвързан списък, който е сортиран и само следващият таймер за стартиране има действителен системен таймер libuv, свързан с него. Когато този таймер се задейства или бъде отменен, следващият в списъка става този, прикачен към действителен системен таймер на libuv. Когато е зададен нов таймер, той просто се вмъква в сортирания списък и, освен ако не стане следващият, който се задейства, той просто седи в списъка и чака своя ред да бъде следващият. Можете да имате хиляди от тях много ефективно.
Ето няколко ресурса за това как работят тези таймери:
Колко едновременни setTimeouts преди проблеми с производителността?
Как nodejs управлява таймери вътрешно
Първата справка съдържа куп коментари от действителния код на nodejs, който описва как работи системата за свързани списъци с таймер и за какво е оптимизирана.
Втората статия ви дава описание на малко по-високо ниво за това как е организирано.
Има и други възможности за ефективност, така че когато един таймер стигне до началото на списъка и се задейства, след извикване на това обратно извикване, node.js проверява предната част на списъка за всякакви други таймери, които вече също са готови за задействане. Това ще почисти всички други таймери със същото „целево време“ като първия, както и всички други, които са настъпили, докато тези различни други обратни извиквания са изпълнявани.
Когато имате хиляди, ще отнеме малко повече време, за да вмъкнете нов таймер в сортирания свързан списък, ако има много таймери вътре, но след като бъде вмъкнат, едва ли има значение колко има, защото той винаги разглежда само следващият да стреля. Така че процесът на седене там с дори десетки хиляди изчакващи таймери е само един системен таймер (представляващ следващото събитие на таймера, което ще се задейства) и куп данни. Всички тези данни за другите бъдещи таймери не ви струват нищо просто да седите там.
За Javascript, подобно на първото решение на python, бих могъл да създам толкова setTimeouts, колкото е необходимо, но проблемът е, че всички изчаквания работят в основната нишка, но както казах, задачите не са ресурсоемки и се нуждая само от точност за второ.
Струва ми се, че nodejs може да се справи с вашето количество setTimeout() обажда се добре. Ако имате проблем в node.js, това няма да се дължи на броя на таймери, но ще трябва да сте сигурни, че прилагате достатъчно CPU към проблема, ако имате повече работа за обработка, отколкото едно ядро може да се справи. Можете да разширите използването на ядрото с клъстериране на nodejs или с работна опашка, която използва Worker Threads или други процеси на nodejs, за да помогне при обработката. node.js сам по себе си е много ефективен с всичко, свързано с I/O, така че стига да не извършвате изчисления с интензивно CPU, една нишка node.js може да се справи с много обработка на събития.
Имайте предвид, че таймерите на Javascript не гарантират точност. Ако блокирате процесора, някои таймери ще се задействат по-късно от планираното, защото не са изпреварващи. Но ако задачите ви не натоварват процесора, тогава може да сте добре.
