Najlepsze rozwiązania i przewodnik rozwiązywania problemów dla aplikacji węzłów w systemie aplikacja systemu Azure Service Windows

W tym artykule przedstawiono najlepsze rozwiązania i kroki rozwiązywania problemów dla aplikacji Node.js systemu Windows działających w usłudze aplikacja systemu Azure Service (z programem iisnode).

Ostrzeżenie

Podczas rozwiązywania problemów z lokacją produkcyjną należy zachować ostrożność. Zaleceniem jest rozwiązanie problemu z aplikacją w konfiguracji nieprodukcyjnej, na przykład miejsca przejściowego, a gdy problem zostanie rozwiązany, zamień miejsce przejściowe na miejsce produkcyjne.

Konfiguracja węzła IISNODE

Ten plik schematu zawiera wszystkie ustawienia, które można skonfigurować dla programu iisnode. Niektóre ustawienia, które są przydatne dla aplikacji:

nodeProcessCountPerApplication

To ustawienie steruje liczbą uruchomionych procesów węzłów dla aplikacji usług IIS. Domyślna wartość wynosi 1. Możesz uruchomić dowolną liczbę plików node.exes jako liczbę procesorów wirtualnych maszyn wirtualnych, zmieniając wartość na 0. Zalecana wartość to 0 dla większości aplikacji, dzięki czemu można używać wszystkich procesorów wirtualnych na maszynie. Node.exe jest jednowątkowy, więc jeden node.exe zużywa maksymalnie 1 procesor wirtualny. Aby uzyskać maksymalną wydajność z aplikacji węzła, chcesz użyć wszystkich procesorów wirtualnych.

nodeProcessCommandLine

To ustawienie steruje ścieżką do node.exe. Tę wartość można ustawić tak, aby wskazywała node.exe wersję.

maxConcurrentRequestsPerProcess

To ustawienie steruje maksymalną liczbą współbieżnych żądań wysyłanych przez program iisnode do każdego node.exe. W usłudze aplikacja systemu Azure wartość domyślna to Nieskończona. Możesz skonfigurować wartość w zależności od liczby żądań odbieranych przez aplikację i szybkości przetwarzania poszczególnych żądań przez aplikację.

maxNamedPipeConnectionRetry

To ustawienie steruje maksymalną liczbą ponownych prób w programie iisnode, co powoduje, że połączenie na nazwanym potoku wysyła żądania do node.exe. To ustawienie w połączeniu z nazwanePipeConnectionRetryDelay określa całkowity limit czasu każdego żądania w programie iisnode. Wartość domyślna to 200 w usłudze aplikacja systemu Azure. Łączny limit czasu w sekundach = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

namedPipeConnectionRetryDelay

To ustawienie steruje czasem oczekiwania (w ms) iisnode między poszczególnymi ponownymi próbami, aby wysłać żądanie do node.exe przez nazwany potok. Wartość domyślna to 250 ms. Łączny limit czasu w sekundach = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

Domyślnie łączny limit czasu w programie iisnode w usłudze aplikacja systemu Azure wynosi 200 * 250 ms = 50 sekund.

logDirectory

To ustawienie steruje katalog, w którym iisnode rejestruje stdout/stderr. Wartość domyślna to iisnode, czyli katalog główny skryptu (katalog, w którym znajduje się główny server.js)

debuggerExtensionDll

To ustawienie steruje wersją narzędzia iisnode inspektora węzła podczas debugowania aplikacji węzła. Obecnie iisnode-inspector-0.7.3.dll i iisnode-inspector.dll są jedynymi dwoma prawidłowymi wartościami tego ustawienia. Wartość domyślna to iisnode-inspector-0.7.3.dll. Wersja iisnode-inspector-0.7.3.dll używa węzła-inspector-0.7.3 i używa gniazd internetowych. Włącz gniazda internetowe w aplikacji internetowej platformy Azure, aby używać tej wersji.

flushResponse

Domyślne zachowanie usług IIS polega na buforowaniu danych odpowiedzi do 4 MB przed opróżnieniem lub do końca odpowiedzi, w zależności od tego, co nastąpi wcześniej. Program iisnode oferuje ustawienie konfiguracji, aby zastąpić to zachowanie: aby opróżnić fragment treści jednostki odpowiedzi, gdy tylko program iisnode odbierze go z node.exe, należy ustawić atrybut iisnode/@flushResponse w pliku web.config na wartość "true":

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

Włącz opróżnianie każdego fragmentu treści jednostki odpowiedzi dodaje obciążenie wydajności, które zmniejsza przepływność systemu o ok. 5% (od wersji 0.1.13). Najlepiej ograniczyć zakres tego ustawienia tylko do punktów końcowych, które wymagają przesyłania strumieniowego odpowiedzi (na przykład przy użyciu <location> elementu w pliku web.config)

Oprócz tego w przypadku aplikacji przesyłania strumieniowego należy również ustawić wartość responseBufferLimit programu obsługi węzła iis na wartość 0.

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

watchedFiles

Rozdzielana średnikami lista plików, które są obserwowane pod kątem zmian. Każda zmiana pliku powoduje odtwarzanie aplikacji. Każdy wpis składa się z opcjonalnej nazwy katalogu, a także wymaganej nazwy pliku, które są powiązane z katalogiem, w którym znajduje się główny punkt wejścia aplikacji. Symbole wieloznaczne są dozwolone tylko w części nazwy pliku. Domyślna wartość to *.js;iisnode.yml

reycleSignalEnabled

Wartość domyślna to false. Jeśli ta opcja jest włączona, aplikacja węzła może nawiązać połączenie z nazwanym potokiem (zmienną środowiskową IISNODE_CONTROL_PIPE) i wysłać komunikat "odtwarzanie". Powoduje to, że w3wp można bezpiecznie odzyskać.

idlePageOutTimePeriod

Wartość domyślna to 0, co oznacza, że ta funkcja jest wyłączona. Po ustawieniu wartości większej niż 0 węzeł iisnode wyświetli wszystkie procesy podrzędne co "idlePageOutTimePeriod" w milisekundach. Zapoznaj się z dokumentacją , aby dowiedzieć się, co oznacza strona. To ustawienie jest przydatne w przypadku aplikacji, które zużywają dużą ilość pamięci i chcą od czasu do czasu zwolnić pamięć RAM na dysku.

Ostrzeżenie

Należy zachować ostrożność podczas włączania następujących ustawień konfiguracji w aplikacjach produkcyjnych. Zaleceniem jest, aby nie włączać ich w aplikacjach produkcyjnych na żywo.

debugHeaderEnabled

Wartość domyślna to false. Jeśli ustawiono wartość true, węzeł iisnode dodaje nagłówek iisnode-debug odpowiedzi HTTP do każdej odpowiedzi HTTP, która wysyła wartość nagłówka iisnode-debug jest adresem URL. Poszczególne informacje diagnostyczne można uzyskać, przeglądając fragment adresu URL, jednak wizualizacja jest dostępna, otwierając adres URL w przeglądarce.

rejestrowanieEnabled

To ustawienie steruje rejestrowaniem stdout i stderr przez iisnode. Program Iisnode przechwytuje element stdout/stderr z procesów węzła, które uruchamia i zapisuje w katalogu określonym w ustawieniu "logDirectory". Po włączeniu tej opcji aplikacja zapisuje dzienniki w systemie plików i w zależności od ilości rejestrowania wykonywanego przez aplikację może mieć wpływ na wydajność.

devErrorsEnabled

Wartość domyślna to false. Po ustawieniu wartości true program iisnode wyświetla kod stanu HTTP i kod błędu Win32 w przeglądarce. Kod win32 jest przydatny podczas debugowania niektórych typów problemów.

debugEnabled (nie włączaj w witrynie produkcyjnej na żywo)

To ustawienie steruje funkcją debugowania. Węzeł Iisnode jest zintegrowany z inspektorem węzła. Włączenie tego ustawienia powoduje włączenie debugowania aplikacji node. Po włączeniu tego ustawienia węzeł iisnode tworzy pliki inspektora węzła w katalogu "debuggerVirtualDir" w pierwszym żądaniu debugowania do aplikacji węzła. Inspektor węzła można załadować, wysyłając żądanie do http://yoursite/server.js/debug. Segment adresu URL debugowania można kontrolować za pomocą ustawienia "debuggerPathSegment". Domyślnie debuggerPathSegment='debug'. Można na przykład ustawić debuggerPathSegment identyfikator GUID, aby utrudnić odnajdywanie ich przez inne osoby.

Aby uzyskać więcej informacji na temat debugowania, zobacz Debugowanie aplikacji Node.js w systemie Windows .

Scenariusze i zalecenia/rozwiązywanie problemów

Moja aplikacja węzła wykonuje nadmierne wywołania wychodzące

Wiele aplikacji nawiązuje połączenia wychodzące w ramach normalnego działania. Jeśli na przykład nadejdzie żądanie, aplikacja platformy Node może kontaktować się z interfejsem API REST w innej lokalizacji, aby uzyskać informacje potrzebne do przetworzenia żądania. Podczas wysyłania wywołań HTTP lub HTTPS warto używać agenta utrzymywania aktywności. Możesz użyć modułu agentkeepalive jako agenta keep alive podczas wykonywania tych wywołań wychodzących.

Moduł agentkeepalive zapewnia ponowne użycie gniazd na maszynie wirtualnej aplikacji internetowej platformy Azure. Utworzenie nowego gniazda dla każdego żądania wychodzącego powoduje dodanie obciążenia do aplikacji. Ponowne użycie gniazd przez aplikację dla żądań wychodzących gwarantuje, że aplikacja nie przekracza maksymalnej liczby obiektówocket przydzielonych na maszynę wirtualną. Zaleceniem aplikacja systemu Azure Service jest ustawienie wartości maxSockets agentKeepAlive na sumę (4 wystąpienia node.exe * 32 maxSockets/instance) 128 gniazd na maszynę wirtualną.

Przykładowa konfiguracja agentKeepALive :

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

Ważne

W tym przykładzie założono, że masz 4 node.exe uruchomione na maszynie wirtualnej. Jeśli na maszynie wirtualnej jest uruchomiona inna liczba node.exe, należy odpowiednio zmodyfikować ustawienie maxSockets.

Moja aplikacja węzła zużywa za dużo procesora CPU

Możesz otrzymać zalecenie od usługi aplikacja systemu Azure Service w portalu dotyczące wysokiego użycia procesora CPU. Możesz również skonfigurować monitory, aby obserwować określone metryki. Podczas sprawdzania użycia procesora CPU na pulpicie nawigacyjnym witryny Azure Portal sprawdź wartości MAX procesora CPU, aby nie przegapić wartości szczytowych. Jeśli uważasz, że aplikacja zużywa zbyt dużo procesora CPU i nie możesz wyjaśnić, dlaczego, możesz profilować aplikację węzła, aby się dowiedzieć.

Profilowanie aplikacji węzła w usłudze aplikacja systemu Azure przy użyciu programu V8-Profiler

Załóżmy na przykład, że masz aplikację hello world, którą chcesz profilować w następujący sposób:

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);

Przejdź do witryny konsoli debugowania https://yoursite.scm.azurewebsites.net/DebugConsole

Przejdź do katalogu site/wwwroot. Zostanie wyświetlony wiersz polecenia, jak pokazano w poniższym przykładzie:

Uruchom polecenie npm install v8-profiler.

To polecenie instaluje program v8-profiler w katalogu node_modules i wszystkie jego zależności. Teraz zmodyfikuj server.js, aby profilować aplikację.

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);

Poprzednie profile kodu funkcja WriteConsoleLog, a następnie zapisuje dane wyjściowe profilu w pliku "profile.cpuprofile" w witrynie wwwroot. Wyślij żądanie do aplikacji. Zostanie wyświetlony plik "profile.cpuprofile" utworzony w witrynie wwwroot.

Pobierz ten plik i otwórz go za pomocą narzędzi Chrome F12. Naciśnij F12 w przeglądarce Chrome, a następnie wybierz kartę Profile. Wybierz przycisk Załaduj. Wybierz pobrany plik profile.cpuprofile. Kliknij właśnie załadowany profil.

Widać, że 95% czasu zostało zużyte przez funkcję WriteConsoleLog. Dane wyjściowe pokazują również dokładne numery wierszy i pliki źródłowe, które spowodowały problem.

Moja aplikacja węzła zużywa za dużo pamięci

Jeśli aplikacja zużywa zbyt dużo pamięci, w portalu zostanie wyświetlone powiadomienie z usługi aplikacja systemu Azure Service o wysokim zużyciu pamięci. Możesz skonfigurować monitory, aby obserwować określone metryki. Podczas sprawdzania użycia pamięci na pulpicie nawigacyjnym witryny Azure Portal sprawdź wartości MAX dla pamięci, aby nie przegapić wartości szczytowych.

Wykrywanie przecieków i różnice stert dla Node.js

Możesz użyć narzędzia node-memwatch , aby ułatwić identyfikowanie przecieków pamięci. Możesz zainstalować memwatch program podobnie jak v8-profiler i edytować kod w celu przechwytywania i różnicowania ściągnięć w celu zidentyfikowania przecieków pamięci w aplikacji.

Moje node.exe są zabijane losowo

Istnieje kilka powodów, dla których node.exe jest zamykana losowo:

1. Aplikacja zgłasza nieprzechwycone wyjątki — sprawdź plik d:\home\LogFiles\Application\logging-errors.txt, aby uzyskać szczegółowe informacje na temat zgłoszonego wyjątku. Ten plik zawiera ślad stosu, aby ułatwić debugowanie i naprawianie aplikacji.
2. Aplikacja zużywa zbyt dużo pamięci, co wpływa na inne procesy przed rozpoczęciem pracy. Jeśli łączna pamięć maszyny wirtualnej jest bliska 100%, node.exe może zostać zabita przez menedżera procesów. Menedżer procesów zabija niektóre procesy, aby umożliwić innym procesom wykonywanie pewnych zadań. Aby rozwiązać ten problem, sprofiluj aplikację pod kątem przecieków pamięci. Jeśli aplikacja wymaga dużej ilości pamięci, przeprowadź skalowanie w górę do większej maszyny wirtualnej (co zwiększa ilość pamięci RAM dostępnej dla maszyny wirtualnej).

Moja aplikacja węzła nie jest uruchamiana

Jeśli aplikacja zwraca błąd 500 podczas uruchamiania, może istnieć kilka powodów:

1. Node.exe nie znajduje się w prawidłowej lokalizacji. Sprawdź ustawienie nodeProcessCommandLine.
2. Główny plik skryptu nie znajduje się w prawidłowej lokalizacji. Sprawdź plik web.config i upewnij się, że nazwa głównego pliku skryptu w sekcji procedury obsługi jest zgodna z głównym plikiem skryptu.
3. Konfiguracja web.config nie jest poprawna — sprawdź nazwy/wartości ustawień.
4. Zimny start — uruchomienie aplikacji trwa zbyt długo. Jeśli aplikacja trwa dłużej niż (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 sekund, iisnode zwraca błąd 500. Zwiększ wartości tych ustawień, aby dopasować czas rozpoczęcia aplikacji, aby zapobiec przekroczeniu limitu czasu w programie iisnode i zwracaniu błędu 500.

Moja aplikacja węzła uległa awarii

Aplikacja zgłasza nieuchwycone wyjątki — sprawdź d:\\home\\LogFiles\\Application\\logging-errors.txt plik, aby uzyskać szczegółowe informacje na temat zgłoszonego wyjątku. Ten plik zawiera ślad stosu, aby ułatwić diagnozowanie i naprawianie aplikacji.

Uruchomienie aplikacji węzła zajmuje zbyt dużo czasu (zimny start)

Częstą przyczyną długich czasów uruchamiania aplikacji jest duża liczba plików w node_modules. Aplikacja próbuje załadować większość tych plików podczas uruchamiania. Domyślnie pliki są przechowywane w udziale sieciowym w usłudze aplikacja systemu Azure Service, ładowanie wielu plików może zająć trochę czasu. Oto niektóre rozwiązania, które przyspieszają ten proces:

1. Spróbuj załadować node_modules i nie załaduj wszystkich modułów na początku aplikacji. Aby załadować moduły z opóźnieniem, wywołanie metody require('module') powinno zostać wykonane, gdy moduł jest rzeczywiście potrzebny w funkcji przed pierwszym wykonaniem kodu modułu.
2. usługa aplikacja systemu Azure oferuje funkcję o nazwie lokalna pamięć podręczna. Ta funkcja kopiuje zawartość z udziału sieciowego do dysku lokalnego na maszynie wirtualnej. Ponieważ pliki są lokalne, czas ładowania node_modules jest znacznie krótszy.

Stan http i podstatuły programu IISNODE

Plik cnodeconstants źródłowy zawiera listę wszystkich możliwych kombinacji stanu/podstatu, które iisnode może zwrócić z powodu błędu.

Włącz usługę FREB dla aplikacji, aby wyświetlić kod błędu win32 (upewnij się, że usługa FREB jest włączona tylko w lokacjach nieprodukcyjnych ze względu na wydajność).

Stan http	Stan podrzędny HTTP	Możliwe przyczyny?
500	1000	Wystąpił problem podczas wysyłania żądania do programu IISNODE — sprawdź, czy node.exe została uruchomiona. Node.exe mogły ulec awarii podczas uruchamiania. Sprawdź konfigurację web.config pod kątem błędów.
500	1001	- Win32Error 0x2 — aplikacja nie odpowiada na adres URL. Sprawdź reguły ponownego zapisywania adresów URL lub sprawdź, czy aplikacja ekspresowa ma zdefiniowane poprawne trasy. - Win32Error 0x6d — nazwany potok jest zajęty — Node.exe nie akceptuje żądań, ponieważ potok jest zajęty. Sprawdź wysokie użycie procesora CPU. - Inne błędy — sprawdź, czy node.exe uległ awarii.
500	1002	Node.exe uległ awarii — sprawdź d:\home\LogFiles\logging-errors.txt pod kątem śledzenia stosu.
500	1003	Problem z konfiguracją potoku — konfiguracja nazwanego potoku jest niepoprawna.
500	1004-1018	Wystąpił błąd podczas wysyłania żądania lub przetwarzania odpowiedzi do/z node.exe. Sprawdź, czy node.exe uległ awarii. sprawdź d:\home\LogFiles\logging-errors.txt pod kątem śledzenia stosu.
503	1000	Za mało pamięci, aby przydzielić więcej nazwanych połączeń potoku. Sprawdź, dlaczego aplikacja zużywa tyle pamięci. Sprawdź wartość ustawienia maxConcurrentRequestsPerProcess. Jeśli nie jest nieskończona i masz wiele żądań, zwiększ tę wartość, aby zapobiec temu błędowi.
503	1001	Nie można wysłać żądania do node.exe, ponieważ aplikacja jest odzyskiwane. Po przetworzeniu aplikacji żądania powinny być obsługiwane normalnie.
503	1002	Sprawdź kod błędu win32 z rzeczywistego powodu — nie można wysłać żądania do node.exe.
503	1003	Nazwany potok jest zbyt zajęty — sprawdź, czy node.exe zużywa nadmierne użycie procesora CPU

NODE.exe ma ustawienie o nazwie NODE_PENDING_PIPE_INSTANCES. W usłudze aplikacja systemu Azure ta wartość jest ustawiona na 5000. Oznacza to, że node.exe może akceptować 5000 żądań jednocześnie na nazwanym potoku. Ta wartość powinna być wystarczająca dla większości aplikacji węzłów działających w usłudze aplikacja systemu Azure Service. W usłudze aplikacja systemu Azure nie powinna być widoczna wartość 503.1003 ze względu na wysoką wartość parametruNODE_PENDING_PIPE_INSTANCES

Więcej zasobów

Skorzystaj z tych linków, aby dowiedzieć się więcej o aplikacjach Node.js w usłudze aplikacja systemu Azure Service.

• Get started with Node.js web apps in Azure App Service (Rozpoczynanie pracy z aplikacjami internetowymi Node.js w usłudze Azure App Service)
• How to debug a Node.js web app in Azure App Service (Jak debugować aplikację internetową Node.js w usłudze Azure App Service)
• Using Node.js Modules with Azure applications (Używanie modułów Node.js z aplikacjami platformy Azure)
• Azure App Service Web Apps: Node.js (Aplikacje internetowe w usłudze Azure App Service: Node.js)
• Centrum deweloperów środowiska Node.js
• Exploring the Super Secret Kudu Debug Console (Szczegółowe informacje o ściśle tajnej konsoli debugowania aparatu Kudu)