We use jsreport to render operational reports for a records-management system, and large
reports regularly crash or time out. We built a chunk-and-parallelize workaround that works
well for flat list reports, but it doesn't work for aggregate reports (grouped reports with
subtotals, summary/statistics reports, cross-tabs). Those still go to jsreport as a single
huge render and fail. We'd like to know the recommended architecture for this case.

Environment

• jsreport 4.11.0, Node.js [version], Windows Server [version], hosted under IIS / iisnode

• Server: 8 GB RAM, 2 CPU cores

• Client: .NET 10 API using the jsreport.Client NuGet package

• Recipe: chrome-pdf, engine: handlebars (plus pdfOperations merge of a header template)

• Config (relevant part):

  {
  "templatingEngines": { "timeout": 1200000 },
  "chrome": { "timeout": 1200000 },
  "reportTimeout": 1200000,
  "workers": { "numberOfWorkers": 6 },
  "extensions": {
  "scripts": { "timeout": 1200000 },
  "express": { "inputRequestLimit": "200mb", "renderTimeout": 1200000 }
  }
  }

What fails

• Typical failing report: ~10k+ rows, ~1000 pages expected
• Playground reproduction with synthetic data: https://playground.jsreport.net/w/mdesaiATIMS/HgoUfkTW
• It did not let me save the full data with 35k rows that crashed the container in production environment.

Our current workaround (works for flat lists)

A SQL stored procedure returns the whole dataset as a JSON array. The .NET API then:

1. Splits the array into chunks of rowsPerPage * pagesPerChunk rows
2. Sends every chunk to jsreport in parallel as separate render requests
3. Adds paging metadata to each chunk so the template knows where it is:
4. Merges the returned PDFs in .NET (PdfSharp) and stamps "Page X of Y" after the merge

This is fast and stable for flat roster or list reports.

Why it doesn't work for aggregate reports

• Group boundaries: chunks are cut by row count, so one group can be split across two chunks.
  The group header repeats and each half prints its own partial subtotal.
• Aggregates are per chunk: subtotals, counts and sums that are computed in Handlebars
  helpers or in the template only see their own chunk's rows. {{Data.length}}-style totals
  repeat in every chunk. This matches what was described in topic 1451 ("Report generation
  takes too much time"), which ended without a solution.
• Summary/statistics reports (counts by category x category, percentages of total) need
  the full dataset to produce even one page, so we can't split them at all. They go as one
  request with the whole JSON, and that is the request that crashes.

Questions

1. What is the recommended way to render large grouped / summary / aggregate reports in
   jsreport 4.x when the full dataset is too big for a single render, but the aggregates need
   all of the data?
2. When a report is split into multiple renders and then merged, how should group subtotals
   and grand totals that span chunks be handled?
3. How should memory and workers be sized for occasional very large renders (worker count,
   per-worker limits, Chrome strategy vs. server RAM)?
4. When a client sends many render requests at the same time, how does jsreport handle them
   beyond numberOfWorkers, and should the client limit how many it sends at once?
5. Are there template, recipe or layout practices you recommend for very long (2,000+ page)
   tabular PDFs with grouping and totals?

Related threads: topic 1451 (totals repeating across parallel chunks), topic 492
(reporting with a lot of data).

Thanks for any guidance!