Azure 应用服务 Windows 版上节点应用程序的最佳做法和故障排除指南Best practices and troubleshooting guide for node applications on Azure App Service Windows

本文介绍 Azure 应用服务上运行的 node 应用程序的最佳实践和故障排除步骤(使用 iisnode)。In this article, you learn best practices and troubleshooting steps for node applications running on Azure App Service (with iisnode).

Warning

在生产站点上使用故障排除步骤时,请格外小心。Use caution when using troubleshooting steps on your production site. 建议在非生产安装(例如过渡槽)上排查应用问题,问题修复后,请交换过渡槽与生产槽。Recommendation is to troubleshoot your app on a non-production setup for example your staging slot and when the issue is fixed, swap your staging slot with your production slot.

IISNODE 配置IISNODE configuration

架构文件显示可针对 iisnode 配置的所有设置。This schema file shows all the settings that you can configure for iisnode. 适用于应用程序的一些设置如下:Some of the settings that are useful for your application:

nodeProcessCountPerApplicationnodeProcessCountPerApplication

此设置控制每个 IIS 应用程序启动的节点进程数目。This setting controls the number of node processes that are launched per IIS application. 默认值为 1。The default value is 1. 可将此值设置为 0,启动与 VM vCPU 计数一样多的 node.exe。You can launch as many node.exes as your VM vCPU count by changing the value to 0. 大多数应用程序的建议值为 0,以便利用计算机上的所有 vCPU。The recommended value is 0 for most applications so you can use all of the vCPUs on your machine. Node.exe 占用单线程,因此,一个 node.exe 最多消耗用 1 个 vCPU。Node.exe is single-threaded so one node.exe consumes a maximum of 1 vCPU. 要让 node 应用程序发挥最大性能,可以利用所有 vCPU。To get maximum performance out of your node application, you want to use all vCPUs.

nodeProcessCommandLinenodeProcessCommandLine

此设置控制 node.exe 的路径。This setting controls the path to the node.exe. 可以设置此值以指向 node.exe 版本。You can set this value to point to your node.exe version.

maxConcurrentRequestsPerProcessmaxConcurrentRequestsPerProcess

此设置控制 iisnode 发送给每个 node.exe 的并发请求数目上限。This setting controls the maximum number of concurrent requests sent by iisnode to each node.exe. 在 Azure 应用服务中,默认值为“无限”。On Azure App Service, the default value is Infinite. 可以根据应用程序收到的请求数目以及应用程序处理每个请求的速度来配置此值。You can configure the value depending on how many requests your application receives and how fast your application processes each request.

maxNamedPipeConnectionRetrymaxNamedPipeConnectionRetry

此设置控制 iisnode 在命名管道上重试连接,以将请求发送到 node.exe 的次数上限。This setting controls the maximum number of times iisnode retries making the connection on the named pipe to send the requests to node.exe. 此设置与 namedPipeConnectionRetryDelay 结合使用,可确定 iisnode 内每个请求的总超时。This setting in combination with namedPipeConnectionRetryDelay determines the total timeout of each request within iisnode. 在 Azure 应用服务中,默认值为 200。The default value is 200 on Azure App Service. 总超时(秒)= (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000Total Timeout in seconds = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

namedPipeConnectionRetryDelaynamedPipeConnectionRetryDelay

此设置控制 iisnode 在每次重试通过命名管道将请求发送到 node.exe 之间所要等待的时间(毫秒)。This setting controls the amount of time (in ms) iisnode waits between each retry to send the request to node.exe over the named pipe. 默认值为 250 毫秒。The default value is 250 ms. 总超时(秒)= (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000Total Timeout in seconds = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

在 Azure 应用服务中,iisnode 的总超时默认为 200 * 250 毫秒 = 50 秒。By default, the total timeout in iisnode on Azure App Service is 200 * 250 ms = 50 seconds.

logDirectorylogDirectory

此设置控制 iisnode 用于记录 stdout/stderr 的目录。This setting controls the directory where iisnode logs stdout/stderr. 默认值是相对于主要脚本目录(主要 server.js 所在的目录)的 iisnodeThe default value is iisnode, which is relative to the main script directory (directory where main server.js is present)

debuggerExtensionDlldebuggerExtensionDll

此设置控制 iisnode 在调试 node 应用程序时使用的节点检查器版本。This setting controls what version of node-inspector iisnode uses when debugging your node application. iisnode-inspector-0.7.3.dll 和 iisnode-inspector.dll 目前是此设置仅有的两个有效值。Currently, iisnode-inspector-0.7.3.dll and iisnode-inspector.dll are the only two valid values for this setting. 默认值为 iisnode-inspector-0.7.3.dll。The default value is iisnode-inspector-0.7.3.dll. iisnode-inspector-0.7.3.dll 版本使用 node-inspector-0.7.3 并使用 Web 套接字。The iisnode-inspector-0.7.3.dll version uses node-inspector-0.7.3 and uses web sockets. 在 Azure Web 应用中启用 Web 套接字以使用此版本。Enable web sockets on your Azure webapp to use this version. 有关如何将 iisnode 配置为使用新 node-inspector 的更多详细信息,请参阅 https://ranjithblogs.chinacloudsites.cn/?p=98See https://ranjithblogs.chinacloudsites.cn/?p=98 for more details on how to configure iisnode to use the new node-inspector.

flushResponseflushResponse

IIS 的默认行为是在刷新之前或直到响应结束时(以较早出现者为准),缓冲最多 4 MB 的响应数据。The default behavior of IIS is that it buffers response data up to 4 MB before flushing, or until the end of the response, whichever comes first. iisnode 会提供配置设置来替代此行为:若要在 iisnode 从 node.exe 收到响应实体主体片段时立刻刷新该片段,需在 web.config 中将 iisnode/@flushResponse 属性设置为“true”:iisnode offers a configuration setting to override this behavior: to flush a fragment of the response entity body as soon as iisnode receives it from node.exe, you need to set the iisnode/@flushResponse attribute in web.config to 'true':

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

启用每个响应实体主体片段的刷新会增大性能开销,但会降低约 5% 的系统吞吐量(从 v0.1.13 起)。Enable the flushing of every fragment of the response entity body adds performance overhead that reduces the throughput of the system by ~5% (as of v0.1.13). 最好将此设置的范围限定于需要响应流式处理的终结点(例如,在 web.config 中使用 <location> 元素)The best to scope this setting only to endpoints that require response streaming (for example, using the <location> element in the web.config)

除此之外,对于流式处理应用程序,必须将 iisnode 处理程序的 responseBufferLimit 设置为 0。In addition to this, for streaming applications, you must also set responseBufferLimit of your iisnode handler to 0.

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

watchedFileswatchedFiles

一个以分号分隔的文件列表,系统将监视其更改。A semi-colon separated list of files that are watched for changes. 任何文件更改会导致应用程序回收。Any change to a file causes the application to recycle. 每个条目都包含可选目录名称,以及相对于主要应用程序入口点所在目录的必要文件名。Each entry consists of an optional directory name as well as a required file name, which are relative to the directory where the main application entry point is located. 只有文件名部分可以使用通配符。Wild cards are allowed in the file name portion only. 默认值为 *.js;iisnode.ymlThe default value is *.js;iisnode.yml

recycleSignalEnabledrecycleSignalEnabled

默认值为 false。The default value is false. 如果启用,节点应用程序可以连接到命名管道(环境变量 IISNODE_CONTROL_PIPE)并发送“回收”消息。If enabled, your node application can connect to a named pipe (environment variable IISNODE_CONTROL_PIPE) and send a "recycle" message. 可以通过此方式正常回收 w3wp。This causes the w3wp to recycle gracefully.

idlePageOutTimePeriodidlePageOutTimePeriod

默认值为 0,表示已禁用此功能。The default value is 0, which means this feature is disabled. 如果设置为大于 0 的值,iisnode 会每隔“idlePageOutTimePeriod”毫秒将其所有子进程移出分页。When set to some value greater than 0, iisnode will page out all its child processes every 'idlePageOutTimePeriod' in milliseconds. 若要了解移出分页的含义,请参考文档See documentation to understand what page out means. 对于消耗大量内存并且偶尔想要将内存页出至磁盘以释放 RAM 的应用程序,此设置很有用。This setting is useful for applications that consume a high amount of memory and want to page out memory to disk occasionally to free up RAM.

Warning

在生产应用程序上启用以下配置设置时,请格外小心。Use caution when enabling the following configuration settings on production applications. 建议不要在实际生产应用程序上启用它们。The recommendation is to not enable them on live production applications.

debugHeaderEnableddebugHeaderEnabled

默认值为 false。The default value is false. 如果设置为 true,iisnode 会将 HTTP 响应标头 iisnode-debug 添加到它所发送的每个 HTTP 响应,iisnode-debug 标头值是一个 URL。If set to true, iisnode adds an HTTP response header iisnode-debug to every HTTP response it sends the iisnode-debug header value is a URL. 查看 URL 片段即可收集各项诊断信息,但在浏览器中打开该 URL 可达到更好的视觉效果。Individual pieces of diagnostic information can be obtained by looking at the URL fragment, however, a visualization is available by opening the URL in a browser.

loggingEnabledloggingEnabled

此设置控制 iisnode 记录 stdout 和 stderr 的功能。This setting controls the logging of stdout and stderr by iisnode. Iisnode 从它所启动的节点进程捕获 stdout/stderr,并写入到“logDirectory”设置中指定的目录。Iisnode captures stdout/stderr from node processes it launches and writes to the directory specified in the 'logDirectory' setting. 一旦启用,应用程序会将日志写入文件系统,这可能会影响性能,但具体要视应用程序完成的日志记录量而定。Once this is enabled, your application writes logs to the file system and depending on the amount of logging done by the application, there could be performance implications.

devErrorsEnableddevErrorsEnabled

默认值为 false。The default value is false. 如果设置为 true,iisnode 会在浏览器上显示 HTTP 状态代码和 Win32 错误代码。When set to true, iisnode displays the HTTP status code and Win32 error code on your browser. 在调试特定类型的问题时,win32 代码很有用。The win32 code is helpful in debugging certain types of issues.

debuggingEnabled(请勿在实际生产站点上启用)debuggingEnabled (do not enable on live production site)

此设置控制调试功能。This setting controls debugging feature. Iisnode 与节点检查器集成。Iisnode is integrated with node-inspector. 通过启用此设置,可启用节点应用程序的调试功能。By enabling this setting, you enable debugging of your node application. 启用此设置后,iisnode 会在对 Node 应用程序发出第一个调试请求时,在“debuggerVirtualDir”目录中创建 node-inspector 文件。Upon enabling this setting, iisnode creates node-inspector files in 'debuggerVirtualDir' directory on the first debug request to your node application. 可将请求发送到 http://yoursite/server.js/debug,以加载 node-inspector。You can load the node-inspector by sending a request to http://yoursite/server.js/debug. 可以使用“debuggerPathSegment”设置来控制调试 URL 段。You can control the debug URL segment with 'debuggerPathSegment' setting. 默认情况下,debuggerPathSegment='debug'。By default, debuggerPathSegment='debug'. 可将 debuggerPathSegment 设置为 GUID 之类的值,这样,其他人就更难发现。You can set debuggerPathSegment to a GUID, for example, so that it is more difficult to be discovered by others.

有关调试的详细信息,请参阅在 Windows 上调试 node.js 应用程序Read Debug node.js applications on Windows for more details on debugging.

方案和建议/故障排除Scenarios and recommendations/troubleshooting

Node 应用程序发出的出站调用过多My node application is making excessive outbound calls

许多应用程序想要在其定期操作中进行出站连接。Many applications would want to make outbound connections as part of their regular operation. 例如,请求传入时,节点应用程序会想连接别处的 REST API,并获取一些信息来处理请求。For example, when a request comes in, your node app would want to contact a REST API elsewhere and get some information to process the request. 建议在进行 http 或 https 调用时使用保持连接代理。You would want to use a keep alive agent when making http or https calls. 可在进行这些出站调用时,使用 agentkeepalive 模块作为保持连接代理。You could use the agentkeepalive module as your keep alive agent when making these outbound calls.

agentkeepalive 模块确保在 Azure Web 应用 VM 上重复使用套接字。The agentkeepalive module ensures that sockets are reused on your Azure webapp VM. 在每个出站请求中创建新套接字会增大应用程序的开销。Creating a new socket on each outbound request adds overhead to your application. 让应用程序对出站请求重复使用套接字可确保应用程序不会超过为每个 VM 分配的 maxSockets。Having your application reuse sockets for outbound requests ensures that your application doesn't exceed the maxSockets that are allocated per VM. 对于 Azure 应用服务的建议是将 agentKeepAlive maxSockets 值设置为每个 VM 总共 160 个套接字(4 个 node.exe 实例 * 每个实例 40 个 maxSockets)。The recommendation on Azure App Service is to set the agentKeepAlive maxSockets value to a total of (4 instances of node.exe * 40 maxSockets/instance) 160 sockets per VM.

agentKeepALive 配置示例:Example agentKeepALive configuration:

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

Important

此示例假设有 4 个 node.exe 在 VM 上运行。This example assumes you have 4 node.exe running on your VM. 如果有不同数目的 node.exe 在 VM 上运行,则必须相应地修改 maxSockets 设置。If you have a different number of node.exe running on the VM, you must modify the maxSockets setting accordingly.

节点应用程序消耗过多的 CPUMy node application is consuming too much CPU

门户上可能会显示 Azure 应用服务针对高 CPU 消耗量提供的建议。You may receive a recommendation from Azure App Service on your portal about high cpu consumption. 也可将监视器设置为监视某些指标You can also set up monitors to watch for certain metrics. Azure 门户仪表板上检查 CPU 使用率时,请检查 CPU 的最大值,这样才不会错过峰值。When checking the CPU usage on the Azure Portal Dashboard, check the MAX values for CPU so you don't miss the peak values. 如果你认为应用程序消耗了过多的 CPU,但又无法做出解释,可以分析 Node 应用程序来找出原因。If you believe your application is consuming too much CPU and you cannot explain why, you can profile your node application to find out.

在 Azure 应用服务中使用 V8 探查器分析 node 应用程序Profiling your node application on Azure App Service with V8-Profiler

例如,假设需要分析如下所示的 hello world 应用:For example, let's say you have a hello world app that you want to profile as follows:

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

转到调试控制台站点 https://yoursite.scm.chinacloudsites.cn/DebugConsoleGo to the Debug Console site https://yoursite.scm.chinacloudsites.cn/DebugConsole

进入 site/wwwroot 目录。Go into your site/wwwroot directory. 将会看到一个命令提示符,如以下示例所示:You see a command prompt as shown in the following example:

运行命令 npm install v8-profilerRun the command npm install v8-profiler.

此命令在 node_modules 目录及其所有依赖项之下安装 v8-profiler。This command installs the v8-profiler under node_modules directory and all of its dependencies. 现在,编辑 server.js 以分析应用程序。Now, edit your server.js to profile your application.

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

上述代码将会分析 WriteConsoleLog 函数,然后将配置文件输出写入站点 wwwroot 下的“profile.cpuprofile”文件。The preceding code profiles the WriteConsoleLog function and then writes the profile output to the 'profile.cpuprofile' file under your site wwwroot. 将请求发送到应用程序。Send a request to your application. 站点 wwwroot 下会显示所创建的“profile.cpuprofile”文件。You see a 'profile.cpuprofile' file created under your site wwwroot.

请下载此文件,并使用 Chrome F12 工具将其打开。Download this file and open it with Chrome F12 Tools. 在 Chrome 中按 F12,并选择“配置文件”选项卡。 单击“加载”按钮。 Press F12 on Chrome, then choose the Profiles tab. Choose the Load button. 选择下载的 profile.cpuprofile 文件。Select your profile.cpuprofile file that you downloaded. 单击刚加载的配置文件。Click on the profile you just loaded.

可以看到,WriteConsoleLog 函数已耗用 95% 的时间。You can see that 95% of the time was consumed by the WriteConsoleLog function. 输出中还会显示造成此问题的具体行号和源文件。The output also shows you the exact line numbers and source files that caused the issue.

node 应用程序消耗过多的内存My node application is consuming too much memory

如果应用程序消耗过多的内存,门户中会显示 Azure 应用服务针对高内存消耗量提供的建议。If your application is consuming too much memory, you see a notice from Azure App Service on your portal about high memory consumption. 可将监视器设置为监视某些指标You can set up monitors to watch for certain metrics. Azure 门户仪表板上检查内存使用率时,请务必检查内存的最大值,这样才不会错过峰值。When checking the memory usage on the Azure Portal Dashboard, be sure to check the MAX values for memory so you don't miss the peak values.

node.js 的泄漏检测和堆区分Leak detection and Heap Diff for node.js

可以使用 node-memwatch 帮助识别内存泄漏。You could use node-memwatch to help you identify memory leaks. 可以像安装 v8-profiler 一样安装 memwatch,并编辑代码来捕获和区分堆,以找出应用程序中的内存泄漏。You can install memwatch just like v8-profiler and edit your code to capture and diff heaps to identify the memory leaks in your application.

node.exe 随机终止My node.exe's are getting killed randomly

node.exe 随机关闭的原因有多种:There are a few reasons why node.exe is shut down randomly:

  1. 应用程序正在引发未捕获的异常 - 请检查 d:\home\LogFiles\Application\logging-errors.txt 文件,了解有关所引发异常的详细信息。Your application is throwing uncaught exceptions - Check d:\home\LogFiles\Application\logging-errors.txt file for the details on the exception thrown. 此文件提供堆栈跟踪以帮助调试和修复应用程序。This file has the stack trace to help debug and fix your application.
  2. 应用程序消耗过多的内存,导致其他进程无法启动。Your application is consuming too much memory, which is affecting other processes from getting started. 如果 VM 内存总量接近 100%,则进程管理器可能会终止 node.exe。If the total VM memory is close to 100%, your node.exe's could be killed by the process manager. 进程管理器终止某些进程后,其他进程便有机会执行一些工作。Process manager kills some processes to let other processes get a chance to do some work. 若要解决此问题,请探查应用程序中的内存泄漏问题。To fix this issue, profile your application for memory leaks. 如果应用程序需要大量的内存,请纵向扩展为更大的 VM(增加 VM 的可用 RAM)。If your application requires large amounts of memory, scale up to a larger VM (which increases the RAM available to the VM).

节点应用程序未启动My node application does not start

如果应用程序在启动时返回 500 错误,可能有几个原因:If your application is returning 500 Errors when it starts, there could be a few reasons:

  1. Node.exe 未出现在正确的位置。Node.exe is not present at the correct location. 检查 nodeProcessCommandLine 设置。Check nodeProcessCommandLine setting.
  2. 主要脚本文件未出现在正确的位置。Main script file is not present at the correct location. 检查 web.config,确保处理程序节中的主要脚本文件名与主要脚本文件匹配。Check web.config and make sure the name of the main script file in the handlers section matches the main script file.
  3. Web.config 配置不正确 - 检查设置名称/值。Web.config configuration is not correct - check the settings names/values.
  4. 冷启动 - 应用程序的启动时间太长。Cold Start - Your application is taking too long to start. 如果应用程序所花的时间超过 (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 秒,则 iisnode 会返回 500 错误。If your application takes longer than (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 seconds, iisnode returns a 500 error. 增加这些设置的值,使其与应用程序启动时间匹配,防止 iisnode 超时并返回 500 错误。Increase the values of these settings to match your application start time to prevent iisnode from timing out and returning the 500 error.

节点应用程序崩溃My node application crashed

应用程序正在引发未捕获的异常 - 请检查 d:\\home\\LogFiles\\Application\\logging-errors.txt 文件,了解有关所引发异常的详细信息。Your application is throwing uncaught exceptions - Check d:\\home\\LogFiles\\Application\\logging-errors.txt file for the details on the exception thrown. 此文件提供堆栈跟踪以帮助诊断和修复应用程序。This file has the stack trace to help diagnose and fix your application.

node 应用程序的启动时间太长(冷启动)My node application takes too much time to start (Cold Start)

应用程序启动时间过长的最常见原因是 node_modules 中有大量文件。The common cause for long application start times is a high number of files in the node_modules. 应用程序在启动时会尝试加载其中的大多数文件。The application tries to load most of these files when starting. 默认情况下,由于文件存储在 Azure 应用服务的网络共享上,因此加载过多的文件可能需要一段时间。By default, since your files are stored on the network share on Azure App Service, loading many files can take time. 加速此过程的某些解决方法包括:Some solutions to make this process faster are:

  1. 使用 npm3 来安装模块,确保采用平面依赖关系结构,并且没有重复的依赖项。Be sure you have a flat dependency structure and no duplicate dependencies by using npm3 to install your modules.
  2. 尝试延迟加载 node_modules,而不要在应用程序启动时加载所有模块。Try to lazy load your node_modules and not load all of the modules at application start. 若要延迟加载模块,应在首次执行模块代码之前,在函数中真正需要该模块时调用 require('module')。To Lazy load modules, the call to require('module') should be made when you actually need the module within the function before the first execution of module code.
  3. Azure 应用服务提供一项称为本地缓存的功能。Azure App Service offers a feature called local cache. 此功能会将内容从网络共享复制到 VM 上的本地磁盘。This feature copies your content from the network share to the local disk on the VM. 由于文件位于本地,因此 node_modules 的加载速度要快很多。Since the files are local, the load time of node_modules is much faster.

IISNODE http 状态和子状态IISNODE http status and substatus

cnodeconstants 源文件列出了 iisnode 可在发生错误时返回的所有可能的状态/子状态组合。The cnodeconstants source file lists all of the possible status/substatus combinations iisnode can return due to an error.

为应用程序启用 FREB 以查看 win32 错误代码(出于性能方面的原因,请确保只在非生产站点上启用 FREB)。Enable FREB for your application to see the win32 error code (be sure you enable FREB only on non-production sites for performance reasons).

Http 状态Http Status Http 子状态Http Substatus 可能的原因?Possible Reason?
500500 10001000 将请求分派到 IISNODE 时发生某种问题 - 检查 node.exe 是否已启动。There was some issue dispatching the request to IISNODE - Check if node.exe was started. Node.exe 可能在启动时已崩溃。Node.exe could have crashed when starting. 检查 web.config 配置是否有错误。Check your web.config configuration for errors.
500500 10011001 - Win32Error 0x2 - 应用未响应 URL。- Win32Error 0x2 - App is not responding to the URL. 检查 URL 重写规则,或检查是否为 Express 应用定义了正确的路由。Check the URL rewrite rules or check if your express app has the correct routes defined. - Win32Error 0x6d - 命名管道繁忙 - Node.exe 不接受请求,因为管道繁忙。- Win32Error 0x6d - named pipe is busy - Node.exe is not accepting requests because the pipe is busy. 检查 CPU 使用率是否偏高。Check high cpu usage. - 其他错误 - 检查 node.exe 是否已崩溃。- Other errors - check if node.exe crashed.
500500 10021002 Node.exe 崩溃 - 检查 d:\home\LogFiles\logging-errors.txt 中的堆栈跟踪。Node.exe crashed - check d:\home\LogFiles\logging-errors.txt for stack trace.
500500 10031003 管道配置问题 - 命名管道配置不正确。Pipe configuration Issue - The named pipe configuration is incorrect.
500500 1004-10181004-1018 发送请求或处理 node.exe 的相关响应时发生某个错误。There was some error while sending the request or processing the response to/from node.exe. 检查 node.exe 是否已崩溃。Check if node.exe crashed. 检查 d:\home\LogFiles\logging-errors.txt 中的堆栈跟踪。check d:\home\LogFiles\logging-errors.txt for stack trace.
503503 10001000 内存不足,无法分配更多命名管道连接。Not enough memory to allocate more named pipe connections. 检查应用为何耗用大量内存。Check why your app is consuming so much memory. 检查 maxConcurrentRequestsPerProcess 设置值。Check maxConcurrentRequestsPerProcess setting value. 如果此值并非无限,而且有许多请求,请增大此值来防止此错误。If it's not infinite and you have many requests, increase this value to prevent this error.
503503 10011001 无法将请求分派至 node.exe,因为应用程序正在回收。Request could not be dispatched to node.exe because the application is recycling. 应用程序回收之后,应该会正常处理请求。After the application has recycled, requests should be served normally.
503503 10021002 检查 win32 错误代码的实际原因 - 无法将请求分派到 node.exe。Check win32 error code for actual reason - Request could not be dispatched to a node.exe.
503503 10031003 命名管道太忙 - 验证 node.exe 是否正在消耗过多的 CPUNamed pipe is too Busy - Verify if node.exe is consuming excessive CPU

NODE.exe 具有名为 NODE_PENDING_PIPE_INSTANCES 的设置。NODE.exe has a setting called NODE_PENDING_PIPE_INSTANCES. 在 Azure 应用服务中,此值设置为 5000。On Azure App Service, this value is set to 5000. 这表示 node.exe 在命名管道上一次可以接受 5000 个请求。Meaning that node.exe can accept 5000 requests at a time on the named pipe. 此值应足以满足 Azure 应用服务中运行的大多数 node 应用程序。This value should be good enough for most node applications running on Azure App Service. Azure 应用服务中不应出现 503.1003,因为 NODE_PENDING_PIPE_INSTANCES 的值较高You should not see 503.1003 on Azure App Service because of the high value for the NODE_PENDING_PIPE_INSTANCES

更多资源More resources

请访问以下链接,详细了解 Azure App Service 上的 node.js 应用程序。Follow these links to learn more about node.js applications on Azure App Service.