Osvědčené postupy a průvodce odstraňováním potíží pro aplikace uzlů ve službě Aplikace Azure Service Windows

V tomto článku se dozvíte osvědčené postupy a kroky řešení potíží pro aplikace windows Node.js spuštěné ve službě Aplikace Azure Service (se službou iisnode).

Upozorňující

Při použití kroků pro řešení potíží v produkční lokalitě buďte opatrní. Doporučuje se vyřešit potíže s aplikací v neprodukčním nastavení, například v přípravném slotu a v případě, že je problém opravený, prohoďte přípravný slot s produkčním slotem.

Konfigurace MODULU IISNODE

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

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 souborů 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 aplikace uzlu, chcete použít všechny virtuální procesory.

nodeProcessCommandLine

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ě Aplikace Azure 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 v Aplikace Azure Service. Celkový časový limit v sekundách = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

namedPipeConnectionRetryDelay

Toto nastavení určuje dobu čekání uzlu iisnode (v ms) mezi jednotlivými opakovanými pokusy o odeslání požadavku na node.exe přes pojmenovaný kanál. Výchozí hodnota je 250 ms. Celkový časový limit v sekundách = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

Ve výchozím nastavení je celkový časový limit v modulu iisnode ve službě Aplikace Azure Service 200 × 250 ms = 50 sekund.

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 (adresář, kde je k dispozici hlavní server.js)

debuggerExtensionDll

Toto nastavení určuje, jakou verzi modulu iisnode node používá při ladění aplikace uzlu. V současné době jsou iisnode-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. Povolte webové sokety ve webové aplikaci Azure, aby používaly tuto verzi.

flushResponse

Výchozí chování služby IIS je, že před vyprázdněním uloží data odpovědi do vyrovnávací paměti až 4 MB, nebo až 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 atribut iisnode/@flushResponse ve 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 ~5 % (od v0.1.13). Nejlepší nastavit obor tohoto nastavení pouze na koncové body, které vyžadují streamování odpovědí (například pomocí <location> elementu v souboru web.config)

Kromě toho musíte u streamovaných aplikací nastavit také responseBufferLimit obslužné rutiny iisnode na hodnotu 0.

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

watchedFiles

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

recycleSignalEnabled

Výchozí hodnota je false. Pokud je tato možnost povolená, aplikace uzlu se může připojit k pojmenované kanálu (proměnná prostředí IISNODE_CONTROL_PIPE) a odeslat zprávu "recyklace". 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 zobrazí všechny podřízené procesy každé 'idlePageOutTimePeriod' v milisekundách. Informace o tom, co stránka znamená, najdete v dokumentaci . 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 nastavená hodnota true, služba iisnode přidá hlavičku iisnode-debug odpovědi HTTP do každé odpovědi HTTP, která odešle hodnotu 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.

loggingEnabled

Toto nastavení řídí protokolování stdout a stderr pomocí modulu iisnode. Služba Iisnode zachycuje stdout/stderr z uzlů, 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.

devErrorsEnabled

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íEnabled (nepovolujte na živém produkčním webu)

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 v prvním požadavku na 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 identifikátor GUID, aby bylo obtížnější zjistit ostatní uživatele.

Další podrobnosti o ladění najdete v článku Ladění Node.js aplikacích ve Windows .

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

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

Řada aplikací chce v rámci běžného provozu provádět odchozí připojení. Například při příchodu žádosti může chtít uzlová aplikace kontaktovat rozhraní REST API jinde a získat nějaké informace k jejímu zpracování. Při provádění volání http nebo https byste chtěli použít agenta responzivity. 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í služby Aplikace Azure Service je nastavit hodnotu maxSockets agentKeepAlive na celkový počet (4 instance node.exe * 32 maxSockets/instance) 128 soketů na virtuální počítač.

Příklad konfigurace agentaKeepALive :

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

Důležité

Tento příklad předpokládá, že na virtuálním počítači běží 4 node.exe. Pokud máte na virtuálním počítači spuštěný jiný počet node.exe, musíte odpovídajícím způsobem upravit nastavení maxSockets.

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

Od služby Aplikace Azure na portálu můžete obdržet doporučení 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.

Profilace aplikace uzlu ve službě Aplikace Azure Service pomocí V8-Profiler

Řekněme například, že máte aplikaci hello world, kterou chcete profilovat následujícím způsobem:

const http = require('http');
function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    WriteConsoleLog();
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Přejděte na web konzoly ladění. https://yoursite.scm.azurewebsites.net/DebugConsole

Přejděte do adresáře site/wwwroot. Zobrazí se příkazový řádek, jak je znázorněno v následujícím příkladu:

Spusťte příkaz npm install v8-profiler.

Tento příkaz nainstaluje nástroj v8-profiler pod adresář node_modules a všechny jeho závislosti. Teď upravte server.js a profilujte aplikaci.

const http = require('http');
const profiler = require('v8-profiler');
const fs = require('fs');

function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    profiler.startProfiling('HandleRequest');
    WriteConsoleLog();
    fs.writeFileSync('profile.cpuprofile', JSON.stringify(profiler.stopProfiling('HandleRequest')));
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Předchozí profily kódu writeConsoleLog funkce a pak zapíše výstup profilu do souboru profile.cpuprofile pod web wwwroot. Odešlete žádost do aplikace. Zobrazí se soubor profile.cpuprofile vytvořený na webu wwwroot.

Stáhněte si tento soubor a otevřete ho pomocí nástrojů Chrome F12. Stiskněte klávesu F12 v Chromu a pak zvolte kartu Profily . Zvolte tlačítko Načíst . Vyberte soubor profile.cpuprofile, který jste stáhli. Klikněte na profil, který jste právě načetli.

Vidíte, že funkce WriteConsoleLog spotřebovala 95 % času. Výstup také ukazuje přesná čísla řádků a zdrojové soubory, které způsobily problém.

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

Pokud vaše aplikace spotřebovává příliš mnoho paměti, zobrazí se na portálu oznámení o vysoké spotřebě paměti ze služby Aplikace Azure 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 node.exe se náhodně zabily

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

1. Aplikace vyvolává nezachycené výjimky – zkontrolujte d:\home\LogFiles\Application\logging-errors.txt soubor s podrobnostmi o vyvolané výjimce. Tento soubor obsahuje trasování zásobníku, které pomáhá ladit a opravit aplikaci.
2. Vaše aplikace spotřebovává příliš mnoho paměti, což má vliv na další procesy, které začínají. Pokud je celková paměť virtuálního počítače blízko 100 %, správce procesu může ukončit vaši node.exe. 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ů:

1. Node.exe není ve správném umístění. Zkontrolujte nastavení nodeProcessCommandLine.
2. Hlavní soubor skriptu se nenachází ve správném umístění. Zkontrolujte web.config a ujistěte se, že název hlavního souboru skriptu v části obslužné rutiny odpovídá hlavnímu souboru skriptu.
3. Konfigurace Web.config není správná – zkontrolujte názvy a hodnoty nastavení.
4. Studený start – Spuštění aplikace trvá příliš dlouho. Pokud vaše aplikace trvá déle než (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 sekund, iisnode vrátí 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 vyvolává nezachycené výjimky – Zkontrolujte d:\\home\\LogFiles\\Application\\logging-errors.txt podrobnosti o vyvolané výjimce v souboru. Tento soubor obsahuje trasování zásobníku, které pomáhá diagnostikovat a opravit vaši aplikaci.

Spuštění aplikace uzlu trvá příliš dlouho (studené 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ří:

1. 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 se mělo vyžadovat volání ('module'), když skutečně potřebujete modul v rámci funkce před prvním spuštěním kódu modulu.
2. 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ý cnodeconstants soubor obsahuje seznam všech možných kombinací stavu nebo dílčích stavů iisnode se může vrátit z důvodu chyby.

Povolte freb pro vaši aplikaci, aby se zobrazil kód chyby win32 (nezapomeňte povolit FREB pouze na neprodukčních lokalitách z důvodů výkonu).

Stav HTTP	Podstatus HTTP	Možný důvod?
500	1000	Při odesílání požadavku do modulu IISNODE došlo k nějakému problému – Zkontrolujte, jestli node.exe bylo spuštěno. Node.exe mohlo dojít k chybovému ukončení při spuštění. Zkontrolujte chyby v konfiguraci web.config.
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ímá požadavky, protože kanál je zaneprázdněný. Zkontrolujte vysoké využití procesoru. – Další chyby – zkontrolujte, jestli node.exe došlo k chybě.
500	1 002	Node.exe došlo k chybovému ukončení – zkontrolujte d:\home\LogFiles\logging-errors.txt 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 trasování zásobníku.
503	1000	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 hodnotu nastavení maxConcurrentRequestsPerProcess. 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 z skutečných důvodů – požadavek nelze odeslat do node.exe.
503	1003	Pojmenované kanály jsou příliš zaneprázdněné – Ověřte, jestli node.exe spotřebovávají nadměrné využití procesoru.

NODE.exe má nastavení s názvem NODE_PENDING_PIPE_INSTANCES. V Aplikace Azure Service je tato hodnota nastavená na 5 000. To 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. V Aplikace Azure Service byste neměli vidět hodnotu 503.1003 kvůli vysoké hodnotě službyNODE_PENDING_PIPE_INSTANCES

Další materiály

Další informace o Node.js aplikacích ve službě Aplikace Azure Service najdete na těchto odkazech.

• Začínáme s webovými aplikacemi Node.js ve službě Azure App Service
• Postup ladění webové aplikace Node.js ve službě Azure App Service
• Používání modulů Node.js s aplikacemi Azure
• Azure App Service Web Apps: Node.js
• Středisko pro vývojáře Node.js
• Seznámení se supertajnou konzolou pro ladění modulu Kudu