Osvědčené postupy a řešení potíží pro Node.js

V tomto článku se dozvíte o osvědčených postupech a řešení potíží s Node.js aplikacemi , které běží ve službě Azure App Service pomocí modulu iisnode.

Upozorňující

Při řešení problémů s produkční lokalitou buďte opatrní. Doporučujeme odstraňovat potíže s aplikací v neprodukčním prostředí, jako je vaše vývojové prostředí. Jakmile je problém opravený, vyměňte přípravný slot za produkční slot.

konfigurace modulu iisnode

Tento soubor schématu zobrazuje všechna nastavení, která můžete nakonfigurovat pro modul iisnode. Mezi užitečná nastavení pro vaši aplikaci patří:

nodeProcessCountPerApplication

Toto nastavení řídí počet spuštěných procesů uzlu na aplikaci IIS. Výchozí hodnota je 1. Změnou hodnoty na 0 můžete spustit tolik procesů node.exe jako počet virtuálních procesorů virtuálního počítače. Doporučená hodnota je 0 pro většinu aplikací, takže můžete na svém počítači používat všechny virtuální procesory. Node.exe je jednovláknové, takže jeden node.exe spotřebovává maximálně 1 vCPU. Pokud chcete dosáhnout maximálního výkonu z aplikace uzlu, použijte všechny virtuální procesory.

příkazový řádek procesu uzlu

Toto nastavení řídí cestu k node.exe. Tuto hodnotu můžete nastavit tak, aby odkazovat na vaši verzi node.exe.

maxConcurrentRequestsPerProcess

Toto nastavení řídí maximální počet souběžných požadavků odesílaných službou iisnode do každého node.exe. Ve službě Azure App Service je výchozí hodnota Nekonečná. Hodnotu můžete nakonfigurovat v závislosti na tom, kolik žádostí vaše aplikace přijme a jak rychle vaše aplikace zpracovává jednotlivé požadavky.

maxNamedPipeConnectionRetry

Toto nastavení určuje maximální počet opakování modulu iisnode, aby se připojení na pojmenovaném kanálu odeslalo do node.exe. Toto nastavení v kombinaci s názvem namePipeConnectionRetryDelay určuje celkový časový limit každého požadavku v rámci modulu iisnode. Výchozí hodnota je 200 ve službě Azure App Service. Total Timeout in seconds = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

namedPipeConnectionRetryDelay

Toto nastavení určuje dobu (v ms), kterou služba iisnode čeká mezi jednotlivými opakováními a odešle požadavek na node.exe přes pojmenovaný kanál. Výchozí hodnota je 250 ms. Total Timeout in seconds = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

Ve výchozím nastavení je celkový časový limit v iisnode na App Service 200 * 250 ms = 50 seconds.

logDirectory

Toto nastavení řídí adresář, ve kterém iisnode protokoluje stdout/stderr. Výchozí hodnota je iisnode, která je relativní vzhledem k adresáři hlavního skriptu (kde je k dispozici hlavní server.js ).

debuggerExtensionDll

Toto nastavení určuje, jakou verzi node-inspector používá iisnode při ladění vaší Node.js aplikace. V současné době jsouiisnode-inspector-0.7.3.dll a iisnode-inspector.dll jedinými dvěma platnými hodnotami pro toto nastavení. Výchozí hodnota je iisnode-inspector-0.7.3.dll. Verze iisnode-inspector-0.7.3.dll používá node-inspector-0.7.3 a používá webové sokety. Chcete-li použít tuto verzi, povolte ve webové aplikaci Azure webové sokety.

flushResponse

Ve výchozím nastavení služba IIS ukládá data odpovědí do vyrovnávací paměti až do 4 MB, než dojde k vyprázdnění, nebo do konce odpovědi, podle toho, co nastane dříve. Iisnode nabízí nastavení konfigurace, které toto chování přepíše: pokud chcete vyprázdnit fragment těla entity odpovědi, jakmile ho iisnode přijme z node.exe, musíte nastavit iisnode/@flushResponse atribut v web.config na hodnotu true.

<configuration>
    <system.webServer>
        <!-- ... -->
        <iisnode flushResponse="true" />
    </system.webServer>
</configuration>

Povolení vyprázdnění každého fragmentu těla entity odpovědi zvyšuje režii na výkon, která snižuje propustnost systému o přibližně 5% (od v0.1.13). Nejlepší je nastavit rozsah tohoto nastavení pouze na koncové body, které vyžadují streamování odpovědí (například použití elementu <location> v web.config).

Kromě toho musíte pro aplikace streamování nastavit responseBufferLimit obslužnou rutinu iisnode na hodnotu 0.

<handlers>
    <add name="iisnode" path="app.js" verb="\*" modules="iisnode" responseBufferLimit="0"/>
</handlers>

sledovanéSoubory

Středník oddělený seznam souborů, které se sledují při změnách. Jakákoli změna souboru způsobí recyklaci aplikace. Každá položka se skládá z volitelného názvu adresáře a požadovaného názvu souboru, který je relativní vzhledem k adresáři, kde se nachází hlavní vstupní bod aplikace. Zástupné znaky jsou povoleny pouze v části s názvem souboru. Výchozí hodnota je *.js;iisnode.yml

aktivovánRecycleSignal

Výchozí hodnota je false. Pokud je tato možnost povolená, vaše node aplikace se může připojit k pojmenované rourě (proměnná IISNODE_CONTROL_PIPE prostředí) a odeslat recyklační zprávu. To způsobí, že w3wp recykluje elegantně.

idlePageOutTimePeriod

Výchozí hodnota je 0, což znamená, že tato funkce je zakázaná. Pokud je nastavena hodnota větší než 0, iisnode odesílá všechny své podřízené procesy z paměti každých idlePageOutTimePeriod milisekund. Informace o tom, co stránka out znamená, najdete v tématu Funkce EmptyWorkingSet. Toto nastavení je užitečné pro aplikace, které spotřebovávají velké množství paměti a chtějí občas zvětšovat paměť na disk, aby uvolnily paměť RAM.

Upozorňující

Při povolování následujících nastavení konfigurace v produkčních aplikacích buďte opatrní. Doporučením je nepovolit je v živých produkčních aplikacích.

debugHeaderEnabled

Výchozí hodnota je false. Pokud je nastaveno true, služba iisnode přidá hlavičku odpovědi HTTP iisnode-debug ke každé odpovědi HTTP, kterou odešle, kde hodnota hlavičky iisnode-debug je adresa URL. Jednotlivé diagnostické informace je možné získat tak, že se podíváte na fragment adresy URL, ale vizualizace je k dispozici otevřením adresy URL v prohlížeči.

Protokolování povoleno

Toto nastavení řídí protokolování stdout a stderr pomocí modulu iisnode. Služba iisnode zachycuje stdout/stderr z procesů uzlu, které spouští a zapisuje do adresáře zadaného v nastavení logDirectory . Jakmile je tato možnost povolená, vaše aplikace zapisuje protokoly do systému souborů a v závislosti na množství protokolování provedené aplikací může mít vliv na výkon.

povolenéChybyProVývoj

Výchozí hodnota je false. Pokud je nastavena hodnota true, iisnode zobrazí stavový kód HTTP a kód chyby Win32 v prohlížeči. Kód Win32 je užitečný při ladění určitých typů problémů.

laděníPovoleno

Nepovolujte na živém produkčním serveru.

Toto nastavení řídí funkci ladění. iisnode je integrovaný s node-inspector. Povolením tohoto nastavení povolíte ladění aplikace uzlu. Po povolení tohoto nastavení služba iisnode vytvoří soubory node-inspector v adresáři debuggerVirtualDir při prvním požadavku ladění aplikace uzlu. Kontrolu uzlu můžete načíst odesláním požadavku na http://yoursite/server.js/debug. Segment adresy URL ladění můžete řídit nastavením debuggerPathSegment . Ve výchozím nastavení debuggerPathSegment='debug'. Můžete například nastavit debuggerPathSegment na GUID, aby jej ostatní obtížněji zjistili.

Scénáře a doporučení / řešení potíží

Aplikace uzlu provádí nadměrné odchozí hovory

Řada aplikací chce v rámci pravidelného provozu vytvářet odchozí připojení. Když například přijde požadavek, aplikace uzlu chce kontaktovat rozhraní REST API jinde a získat nějaké informace ke zpracování požadavku. Při provádění volání HTTP nebo HTTPS je vhodné použít agenta keep-alive. Modul agentkeepalive můžete použít jako aktivního agenta při provádění těchto odchozích volání.

Modul agentkeepalive zajišťuje opětovné použití soketů na virtuálním počítači webové aplikace Azure. Vytvoření nového soketu na každém odchozím požadavku zvyšuje režii vaší aplikace. Opětovné použití soketů aplikace pro odchozí požadavky zajistí, že vaše aplikace nepřekročí maximální počet soketů přidělených na virtuální počítač. Doporučení ve službě Azure App Service je nastavit hodnotu maxSockets agentaKeepAlive na celkovou hodnotu (four instances of node.exe * 32 maxSockets/instance) 128 sockets per VM.

Příklad konfigurace agentaKeepALive :

let keepaliveAgent = new Agent({
    maxSockets: 32,
    maxFreeSockets: 10,
    timeout: 60000,
    freeSocketTimeout: 300000
});

Důležité

V tomto příkladu se předpokládá, že máte na virtuálním počítači spuštěné čtyři node.exe instance. Pokud máte jiné číslo, musíte odpovídajícím způsobem upravit nastavení maxSockets.

Aplikace uzlu spotřebovává příliš mnoho procesoru

Na portálu můžete obdržet doporučení od služby Azure App Service týkající se vysoké spotřeby procesoru. Monitorování můžete také nastavit tak, aby sledovala určité metriky. Při kontrole využití procesoru na řídicím panelu webu Azure Portal zkontrolujte hodnoty MAX procesoru, abyste nezmeškali maximální hodnoty. Pokud se domníváte, že vaše aplikace spotřebovává příliš mnoho procesoru a nemůžete vysvětlit proč, můžete profilovat aplikaci uzlu a zjistit ji.

Aplikace uzlu spotřebovává příliš mnoho paměti

Pokud vaše aplikace spotřebovává příliš mnoho paměti, na portálu se zobrazí oznámení o vysoké spotřebě paměti ve službě Azure App Service. Monitorování můžete nastavit tak, aby sledovala určité metriky. Při kontrole využití paměti na řídicím panelu webu Azure Portal nezapomeňte zkontrolovat maximální hodnoty paměti, abyste nezmeškali hodnoty ve špičce.

Detekce úniku a rozdíl haldy pro Node.js

K identifikaci nevrácené paměti můžete použít node-memwatch . Můžete nainstalovat memwatch stejně jako v8-profiler a upravit kód tak, aby zachytával a odhaloval nevracení paměti ve vaší aplikaci.

Moje instance programu node.exe se náhodně ukončí

Existuje několik důvodů, proč node.exe náhodně vypíná:

Vaše aplikace vyvolává nezachycené výjimky. Zkontrolujte soubor d:\home\LogFiles\Application\logging-errors.txt pro podrobnosti o vyvolané výjimce. Tento soubor obsahuje trasování zásobníku, které pomáhá ladit a opravit aplikaci.
Vaše aplikace spotřebovává příliš mnoho paměti, což má vliv na další procesy od začátku. Pokud je celková paměť virtuálního počítače blízko 100%, správce procesů může ukončit vaše node.exe instance. Správce procesů některé procesy zabije, aby ostatní procesy získaly šanci na nějakou práci. Pokud chcete tento problém vyřešit, profilujte aplikaci kvůli nevracení paměti. Pokud vaše aplikace vyžaduje velké množství paměti, vertikálně navyšte kapacitu na větší virtuální počítač (což zvýší dostupnou paměť RAM pro virtuální počítač).

Aplikace uzlu se nespustí

Pokud aplikace při spuštění vrací chyby 500, může to být z několika důvodů:

Node.exe není ve správném umístění. nodeProcessCommandLine Zkontrolujte nastavení.
Hlavní soubor skriptu se nenachází ve správném umístění. Zkontrolujte web.config a ujistěte se, že název souboru hlavního skriptu v části obslužné rutiny odpovídá hlavnímu souboru skriptu.
Web.config konfigurace není správná. Zkontrolujte názvy a hodnoty nastavení.
Chladný start: Spuštění aplikace trvá příliš dlouho. Pokud vaše aplikace trvá déle než (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1,000 seconds, vrátí modul iisnode chybu 500. Zvyšte hodnoty těchto nastavení tak, aby odpovídaly času spuštění vaší aplikace, aby se zabránilo vypršení časového limitu uzlu iisnode a vrácení chyby 500.

Aplikace uzlu se chybově ukončila

Aplikace vyhazuje nezachycené výjimky. Zkontrolujte d:\home\LogFiles\Application\logging-errors.txt pro podrobnosti o vyvolané výjimce. Tento soubor obsahuje trasování zásobníku, které pomáhá diagnostikovat a opravit vaši aplikaci.

Moje Node aplikace trvá příliš dlouho na spuštění (chladné spuštění)

Běžnou příčinou dlouhé doby spuštění aplikace je velký počet souborů v node_modules. Při spuštění se aplikace pokusí načíst většinu těchto souborů. Vzhledem k tomu, že jsou vaše soubory uložené ve sdílené síťové složce ve službě Aplikace Azure Service, může načítání mnoha souborů nějakou dobu trvat. Mezi řešení, která tento proces urychlíte, patří:

Zkuste opožděně načíst node_modules a ne načíst všechny moduly při spuštění aplikace. V případě opožděného načtení modulů by mělo být volání funkce `require('module')` provedeno, jakmile modul ve funkci skutečně potřebujete, před prvním spuštěním kódu tohoto modulu.
služba Aplikace Azure nabízí funkci označovanou jako místní mezipaměť. Tato funkce zkopíruje obsah ze sdílené síťové složky na místní disk na virtuálním počítači. Vzhledem k tomu, že jsou soubory místní, je doba načítání node_modules mnohem rychlejší.

Stav HTTP modulu iisnode a dílčí stav

Zdrojový soubor cnodeconstants obsahuje seznam všech možných kombinací stavů nebo vedlejších stavů, které může iisnode vrátit z důvodu chyby.

Povolte freb pro vaši aplikaci, aby se zobrazil kód chyby Win32. Ujistěte se, že FREB povolíte jenom na neprodukčních webech z důvodu výkonu.

Stav HTTP	Podstatus HTTP	Možný důvod
500	1 000	Při odesílání požadavku do modulu iisnode došlo k nějakému problému. Zkontrolujte, jestli node.exe byla spuštěna. Node.exe mohlo selhat při spuštění. Zkontrolujte svoji konfiguraci web.config pro chyby.
500	1001	– Win32Error 0x2: Aplikace neodpovídá na adresu URL. Zkontrolujte pravidla přepsání adresy URL nebo zkontrolujte, jestli má vaše expresní aplikace definované správné trasy. – Win32Error 0x6d: Pojmenovaný kanál je zaneprázdněn. Node.exe nepřijímají žádosti, protože kanál je zaneprázdněný. Zkontrolujte vysoké využití procesoru. – Další chyby: Zkontrolujte, zda došlo k pádu aplikace node.exe.
500	1 002	Node.exe spadl. Zkontrolujte d:\home\LogFiles\logging-errors.txt pro trasování zásobníku.
500	1003	Problém s konfigurací kanálu Konfigurace pojmenovaného kanálu je nesprávná.
500	1004-1018	Při odesílání požadavku nebo zpracování odpovědi do/z node.exe došlo k chybě. Zkontrolujte, jestli node.exe došlo k chybovému ukončení. Zkontrolujte d:\home\LogFiles\logging-errors.txt pro trasování zásobníku.
503	1 000	Nedostatek paměti pro přidělení více pojmenovaných připojení kanálu. Zkontrolujte, proč vaše aplikace spotřebovává tolik paměti. Zkontrolujte `maxConcurrentRequestsPerProcess` hodnotu nastavení. Pokud není nekonečné a máte mnoho požadavků, zvyšte tuto hodnotu, abyste této chybě zabránili.
503	1001	Požadavek nelze odeslat do node.exe, protože aplikace se recykluje. Po recyklaci aplikace by se požadavky měly obsloužovat normálně.
503	1 002	Zkontrolujte kód chyby Win32 pro skutečný důvod. Požadavek nelze odeslat do node.exe.
503	1003	Pojmenované potrubí je příliš obsazené. Ověřte, jestli node.exe spotřebovává nadměrné zatížení procesoru.

Node.exe má nastavení s názvem NODE_PENDING_PIPE_INSTANCES. V Azure App Service je tato hodnota nastavená na 5000, což znamená, že node.exe může na pojmenovaném kanálu přijmout 5 000 požadavků najednou. Tato hodnota by měla být dostatečná pro většinu aplikací uzlů spuštěných ve službě Aplikace Azure Service. Ve službě Azure App Service byste neměli vidět hodnotu 503.1003 kvůli vysoké hodnotě NODE_PENDING_PIPE_INSTANCES.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-12-13