Sitecore 9.3 + JSS. Under heavy load we see errors in log files:

Exception Message
Exception: System.TimeoutException
Message: 10000ms elapsed without getting a service from the pool.
Source: Sitecore.JavaScriptServices.ViewEngine.Node
  at Sitecore.JavaScriptServices.ViewEngine.Node.GenericConcurrentPool`1.CheckOut()
  at Sitecore.JavaScriptServices.ViewEngine.Node.NodeRenderEngine.Invoke[T](String moduleName, String functionName, Object[] functionArgs)
  at Sitecore.JavaScriptServices.ViewEngine.Presentation.JssRenderer.PerformRender(TextWriter writer, IRenderEngine renderEngine, String moduleName, String functionName, Object[] functionArgs)
  at Sitecore.JavaScriptServices.ViewEngine.Presentation.JssRenderer.Render(TextWriter writer)
  at Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer.Render(Renderer renderer, TextWriter writer, RenderRenderingArgs args)

NodeRenderEngine tryes to render a component and takes a INodeServices from the GenericConcurrentPool but cannot because as I see from the code PoolSize is not defined in the config.

<renderEngine name="nodejs" patch:source="Sitecore.JavaScriptServices.ViewEngine.Node.config">
<instance id="defaults">

              If true, the Node.js instance will accept incoming V8 debugger connections (e.g., from node-inspector).
              The node process is invoked with the "inspect" flag.

              If "launchWithDebugging" is true, the Node.js instance will listen for V8 debugger connections on this port.
              IMPORTANT: Node instances _must_ have unique debugging ports. If you try to create multiple node instances with the same debugger port, those node processes will exit.
              Therefore, it is recommended that you create <instance /> configurations for individual JSS apps / renderings if you wish to use remote SSR debugging features.
 If set, the Node.js instance should restart when any matching file on disk within your project changes. 

              If set, starts the Node.js instance with the specified environment variables.
<var name="NODE_ENV" value="production"/>
 Specifies the maximum duration, in milliseconds, that your .NET code should wait for Node.js RPC calls to return. 
 Specify the path to node to execute. 'node' = resolve using PATH environment variable 

but has value 2 from the <app name="defaults" ... serverSideRenderingWorkerProcesses="2".

So the question is: should I increase the pool size and what is the general rule here besides the 'one per cpu core' coming from the common sense?

2 Answers 2


My case is solved with the node version.

Our hosted environment is azure appservice and node version is 8.

The issue was solved when I changed the latest node version in the app service. Change below in app service

enter image description here

"value": "~18"

From my testing in Prod of a Vue JSS 18 app in integrated mode, on a server with 4 cores, the best performance came from setting serverSideRenderingWorkerProcesses="1". This is counter-intuitive but the results speak for themselves. However I was still getting the issue, just at higher loads.

Sitecore docs:

We do not recommend integrated mode for heavy load production scenarios, because the entire page is server-side rendered using Node.js as a block, not as individual renderings. Therefore, traditional output caching mechanisms become all-or-nothing. In other words, if caching is enabled, it forces caching of the entire page, which is almost always not what is desired.

I think this will always be an issue in integrated mode - it is just a limitation. Better option is to work on getting headless mode working.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.