Hi @Bhanu Pratap,

I not use UltimatePDF as much but i add sloution bcz i aslo facing this in one project.

Here’s a breakdown and some strategies you can consider to improve performance or mitigate the impact:

Why it’s slow

1. Chromium startup overhead – Even headless, launching the rendering engine is expensive.

2. Single-threaded processing – Each PDF generation blocks the thread until the render is done.

3. Complex CSS/JS – Any animations, external fonts, or scripts increase render time.

4. Server load – If multiple users trigger PDFs simultaneously, the process queues up and slows further.

Performance improvement strategies

1. Reuse browser instance

   • Some setups allow you to keep Chromium running instead of starting it fresh per PDF.

   • Check if the component exposes a “persistent session” or “reuse engine” option.

2. Reduce HTML complexity

   • Minimize external fonts, heavy JS, and large images.

   • Inline small CSS instead of external stylesheets.

   • Avoid unnecessary DOM layers.

3. Generate asynchronously

   • Offload PDF generation to background jobs using Timers or Queues.

   • Users can get a “Your PDF is being prepared” message, and then download when ready.

4. Cache PDFs

   • If PDFs are mostly static or template-based, pre-generate or cache them instead of regenerating each request.

5. Consider alternative libraries

   • If speed is more critical than pixel-perfect rendering:

     • ReactivePDF or OutSystems PDF plugin (built-in) is faster for simpler layouts.

     • These won’t fully support modern CSS, but often generate PDFs in <1–2 seconds.

   • Sometimes a hybrid approach works:

     • Use Ultimate PDF only for highly styled documents.

     • Use lightweight PDF generation for simple reports.

6. Server scaling

   • If you must use Ultimate PDF for all requests, consider dedicated workers for PDF generation.

   • Separate PDF generation from the main app to avoid slowing user-facing requests.

 Key insight: Ultimate PDF prioritizes accuracy over speed. If 10–12 seconds per PDF is unacceptable, you either need asynchronous generation + caching or switch to a lighter PDF solution for routine documents.

1. High-level Idea

Instead of generating the PDF synchronously during a user request, we:

1. Save the PDF request info (template, data) in a database table.

2. Trigger a background job (Timer or Queue) to generate the PDF.

3. Store the generated PDF (in database or external storage).

4. Notify the user when ready (email, notification, or “Download” button becomes active).

2. Database Setup

Table: PDF_Request

Column NameTypeNotes

3. User Request Flow

1. User clicks “Generate PDF.”

2. Frontend calls an action to:

   • Create a PDF_Request record with Status = Pending.

   • Return immediately with a message: “Your PDF is being prepared.”

3. Optionally, show a UI notification like a spinner or a “Download PDF” button that is disabled until Status = Completed.

4. Background Job (Timer/Queue)

1. Timer Setup (e.g., runs every few seconds or continuously) or use Reactive Queue in OutSystems.

2. Logic:

   • Query PDF_Request where Status = Pending.

   • For each record:

     1. Set Status = Processing.

     2. Use Ultimate PDF to generate PDF using the stored TemplateName + DataJSON.

     3. Store the binary output in PDF_Binary.

     4. Set Status = Completed and CompletedOn = now().

   • Handle errors:

     • Set Status = Failed and optionally log the error.

5. User Notification / Download

• Option 1: Polling

  • Frontend periodically checks PDF_Request.Status.

  • When Status = Completed, enable the “Download PDF” button.

• Option 2: Push Notification

  • Use OutSystems notifications or email to alert the user that PDF is ready.

6. Optional Enhancements

1. Caching

   • If the same PDF with same data is requested multiple times, skip regeneration.

2. Separate Worker Server

   • For heavy PDF generation, dedicate a server node to run the Timer only. This avoids blocking user-facing requests.

3. Queue Priority

   • You can add a priority column (High, Low) if some PDFs need faster processing.

4. Retry Mechanism

   • For failures, retry 1–2 times before marking as failed.

7. Benefits

• Users never wait 10+ seconds.

• App performance remains responsive.

• Scalable: can generate multiple PDFs in parallel without blocking UI.

Thank You