Rendering error on AWS but not on local docker

[msageryd]

My JSReport server at AWS Fargate renders many heavy reports every day, but one particular report cannot be rendered.

I have seen different errors from the many retries of this report, such as:

• Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
• Protocol error (Page.printToPDF): Printing failed
• Protocol error (IO.read): Target closed

The JSON data is quite large, about 33 MB. If I copy this data to my local JSReport and run it, the complete rendering is finished after about 27 seconds. My local server is ARM64.

• The timeout on the server is set to 10 minutes.
• The server at AWS har 2vCPU and 5GB memory.
• The server is AMD64
• My reports are served from a queue. Ihave set the max concurrent to 1, i.e. no other reports are rendered at the server concurrently.

I tried to upgrade from 4.3 to 4.7, but the problem remains.

How should I move on with this?
Are there any detailed logs I can look at?

My local docker server har 8GB of memory, but it peaks at aprox 1.8GB usage, so this does not seem lika a memory problem, at least not locally.

[msageryd]

Update.
I have now moved the AWS server to ARM64 to mimic my local environment. Problem remains.

I noticed that the report timed out after about 3 minutes, despite my jsreport config states "reportTimeout": 600000,. Are there other timeout settings somewhere? What is "protocolTimeout"?

Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed. ProtocolError: Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.

[admin]

You need to use also the config

"extensions": {
  "chrome-pdf": {
    "launchOptions": { "protocolTimeout": 600000  }
  }
}

This became useful in the later versions of Chrome, we will set this for you in the next release https://github.com/jsreport/jsreport/issues/1202

[admin]

I've updated the config code in previous comment...

[msageryd]

Thanks.
This solved the timeout issue.

The 2vCPU server tops out at 99.5% while rendering this report at AWS. I'm guessing that this CPU overload leads to very long rendering times. I got some suggestions from Claude AI.

Firstly, I increased to 4 vCPU.

I also added some chrome args:

 "args": [
        "--no-sandbox",
        "--disable-gpu",
        "--disable-dev-shm-usage"
      ]

The report now renders at about 40 seconds on Fargate. I had to switch back to AMD64. It seems as is Puppeteer has some problems in the AWS ARM environment. Works great on M2 Mac though.

Is there anything I could do to make the JSReport run on ARM64 at AWS?

[msageryd]

If anyone is interested, or encounters the same problem.

Topping out the CPU is really bad. When it reaches the top, the current report rendering seems to slow down to almost stand-still. I was contemplating setting up a second JSReport server, but that would not have solved our type of load. We have very few renderings (10-20 per day), but sometimes really big reports are rendered. The most important bottleneck in our setup seems to be topping out the CPUs.

The left part of this chart shows three attempts to render a very large report. Each of the attempts timed out after 10 minutes.

To the right in the chart, the same report is rendered two times after upgrading from 2 vCPU to 4 vCPU. Each render took about 40-42 seconds.

The last cpu bump is a smaller report. This particular report was actually rendered successfully with 2 vCPUs a couple of days ago, so I had metrics to compare. With 2vCPUs the smaller report took 14 seconds to render. After the upgrade, the same report took 9 seconds. This is a reasonable performance bump, but its always nice with confirmation.