Has anyone else had problems with 4.6 or 4.7 on Fargate? Both versions works great in local Docker, but when I deploy to AWS Fargate Puppeteer hangs.

I have now upgraded from 4.3.1 to 4.5.0 on my production server. Any further upgrade breaks Puppeteer.

I have logged an issue:
https://github.com/jsreport/jsreport/issues/1207

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.

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?

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.

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.

Update:
I got window.JSREPORT_READY_TO_START to work by ckecking "wait for printing trigger", but the measurement are still taken before automatic page breaks.

I have tried both setTimeout and requestAnimationFrame. Is there no way to await chrome-pdf's automatic page breaking before taking measurements?

I need to measure some elements. This works great with the following concept:

1. In a script tag, iterate alle elements and collect element.getBoundingClientRect()
2. stringify the measures and mashal them to the server side via console.log
3. add measurement data to req.data
4. start a second render where I now have access to the measurements

Unfortunately, I'm having trouble with the timing. I'm currently measuring at window.onload. It seems as chrome-pdf applies the automatic page breaks after my measurements. I.e. the boundingboxes will sometimes relate to the position the element had before chrome-pdf added the automatic pagebreaks.

Is there any way to await the complete layout?

I tried with a simple setTimeout but jsReport does not await such timeouts on the client side.
I also tried to set window.JSREPORT_READY_TO_START = false; and then set it to true after my timeout, but jsReport did not wait for this.

Never mind.
I see that the message is truncated at 1000 characters. This is probably reasonable to not bloat the logs.

I solved it by chunking my console.log calls instead.

New problem.
I'm collecting measurement data from my html elements, put them in an array and stringify before sending the data to the server side via console.log. It seems as if the message gets truncated. Is console.log not a reliable way to marshal data to the server?

I get the feeling that the profile pane in jsReport truncates long strings, and the truncated string is also what is what I get in req.context.logs[i].message.

Solved. I got it to work when I changed recipe to chrome-pdf.
Is this as it should, i.e. console.log at the client side only works for chrome-pdf?