I'm not sure if you want to do the same as I tried. My use case is for the moment not possible due to some external bug.
https://forum.jsreport.net/topic/1233/merging-pdfs-from-download-links-and-creating-a-toc/5

I've been postponing the hunt for a solution to this problem. Until now my solution has been to occationaly shut down jsreport to save the fans on the MBP. Now I have all my Docker images running and Docker is barely noticeable at about 6% CPU. I almost forgot how it was to work with a quiet computer =)

Happy CPU:

Thanks!
"usePolling: false" did the trick.

Do I need to have a different config for the production image?
Will I loose any essential functionality with usePolling: false on an Amazon Linux container? I'm specifically thinking of template updating via Studio.

I should add:

• Before the experiment I upgraded to latest Docker desktop for mac (2.1.0.4)
• macOS 10.14.6, all system updates applied
• Macbook Pro 2018, 32GB RAM, SSD, 2.6GHz core i7

I have done some more testing.

1. Started an empty jsreport container -> 5% CPU
2. Started my container with a bunch of templates -> 300% CPU

The templates are stored in a local mounted volume. I started to remove templates from the mounted volume and discovered that the CPU load went down.

After removing all templates the CPU load was quite acceptable (10-20%). I started to add empty files and discovered that the CPU load is almost proportionate to the number of files.

I think something is going on with the template change monitoring.

Below is a CPU chart from my experiment:

1. Started jsreport with a bunch of templates
2. Removed the templates one by one
3. Added 50 empty files to the data/templates folder
4. Added 50 more empty files
5. No templates exists, but 100 empty files are in the mounted data/templates

I'm using the official 2.6.1 docker image. I've probably had the same problem since 2.5. Today I discovered that jsreport took all cpu.

Here is my Dockerfile:

COPY license-key.txt /app
COPY ./mounted/jsreport.config.json /app
# COPY ./mounted/data /app/data

ENV templatingEngines:strategy in-process
ENV node --max-old-space-size=3072

RUN cd /app && npm install \
  moment \
  moment-timezone \
  intl \
  handlebars-helpers \
  node-fetch \
  jsreport-assets \
  jsreport-static-pdf

The config file:

{
  "httpPort": 5488,
  "allowLocalFilesAccess": true,
  "store": {
    "provider": "fs"
  },
  "blobStorage": {
    "provider": "fs"
  },
  "templatingEngines": {
    "numberOfWorkers": 2,
    "timeout": 600000,
    "strategy": "in-process"
  },
  "chrome": {
    "timeout": 600000
  },
  "extensions": {
    "scripts": {"timeout": 600000},
    "chrome-pdf": {
      "strategy": "chrome-pool",
      "numberOfWorkers": 2
    },
    "express": {
      "inputRequestLimit": "50mb",
      "renderTimeout": 600000
    },
    "child-templates": {
      "parallelLimit": 2
    }
  }
}

Here is the log from starting jsreport until I stopped it. When I started the jsreport container Docker's cpu utilization immediately went from sub 10% to over 300%. The fans also started immediately. There are no logs created while running. The loogs in the below image is from jsreport startup, after this nothing happens in the logs.

What does jsreport do when idle?
I'm running all of my servers in local docker while developing. I have 5 nodejs containers, one nginx, one jsreport and one postgres container.

I'm not rendering reports and I don't have Studio open. I just figured out why my macbook fans are running on max all the time. I thought I stressed the macbook by running that many docker images, but it turns out that jsreport is the sole villain here.

If I stop the jsreport container the cpu % for Docker goes from 300% to 5%. The fans are completely silent if I don't run jsreport.

Here are the iStats history on my 6 cores. Look what happened when I stopped jsreport!

@ThePolymorph I'll chime in with my jsrender experience, if you don't mind.

I started out all-in with jsrender, becuase I thought it was much better than handlebars. But reality caught up and I have now migrated all of my reports to Handlebars. Because:

• Lack of examples in jsreport (seems to be somewhat mitigated now)
• Lack of examples in the public. Handlebars is soo much bigger. it's really easy to get help on Stack Overflow or elsewhere
• I don't know how it is in JSR 2.6, but in 2.5 an older version of jsrender was implemented, some features where not included (for example loop filters)
• I found that helpers could be as powerful in Handlebars as in jsrender.
• I'm now using the helper package handlebars-helpers, both for it's features and as inspiration for my own helpers

Thanks, I'll increase max-old-memory. What do you mean by having a web server in front of jsreport? My jsreport is not available from the outside. All requests comes from another server which serves/distributes my queue jobs. One queue is for report rendering. Why would I need a web server in front of jsreport?

After switching to "in-process" my heavy report works without error. I think it's more to the problem than just bad error reporting. The "Bad request" came after about 4 seconds. Efter switching to in-process the report is rendered in just over a minute.

I do wonder if in-process rendering makes the server more sensitive to overload? After switching to in-process and deliberately overloaded jsreport (10 heavy reports in parallell) the server crashed. I haven't made a side by side comparison, byt my feeling is that before switching to in-process, jsreport could manage more reports in parallell. They took a long time to render, but it didn't crash.

I have now adjusted my queue-handling so I have a separate queue for heavy reports. This queue only puts through one report concurrently. Is this how I have to solve this? I thought that jsreport could handle parallel requests.