multi threading htmltopdfcoonverter

[Roger William Nemeth]

We have a customer that is wanting up to 1.5 million 20kb average html files converted to pdf daily. We launch an exe from a parent .net service app. Each exe runs an htmltopdfconverter that converts 12 html files to pdf. If we are not running the htmltopdfconverter we can launch 50 simultaneous exe's but with the htmltopdf converter we can only get six to 10 of the exe's to convert the files at a time and then we start to get timeouts making the save calls. In testing I created an app that does nothing but converts htmltoPDF with multithreads and the best I have been able to do is just over 800,000 conversions in 24 hours. Looking for input on best practices and upward processing limit of the htmltopdf converter. We have a 64 core VM hotrod machine with 64 gb ram.

[Arumugam Muppidathi]

Hi Roger,

Based on the details you shared, the performance issue isn’t related to the HTML size but to how many Blink instances are being launched in parallel. The Blink engine is heavy, and when too many instances run at the same time, they compete for CPU, memory, and temporary file resources. This leads to slowdowns and eventually causes the save operations to time out.

 

For high‑volume scenarios like yours, the most stable approach is to run a limited number of long‑lived HtmlToPdfConverter instances rather than launching many short‑lived executables. On a 64‑core / 64 GB machine, a practical starting point is 8–12 workers, each processing documents one at a time. Beyond this, the Blink processes begin to interfere with each other, which is why you see a drop in throughput once you cross six to ten instances.

 

It is also important to enable ReuseBrowserProcess = True. When this is disabled, each conversion forces Blink to start from scratch, which adds a significant amount of overhead and increases the number of active Blink processes. Reusing the browser process typically improves conversion speed and stability.  Please refer to the following documentation for more details:
Performance optimization | Syncfusion

 

Another key point is isolating each worker’s temp usage. Instead of creating a new temp folder for every conversion, assign one dedicated temp directory per worker on a fast local disk. This reduces filesystem churn and avoids temporary file locking. Adding antivirus exclusions for these folders also helps prevent intermittent I/O delays.

 

Your command‑line arguments are generally fine, but on Windows we recommend removing --no-sandbox unless you specifically need it. This setting is useful in containerized Linux environments but can cause more instability on Windows.

 

Writing PDFs to a local drive first, then moving them to network storage afterward, also reduces contention during pdf.Save(). Increasing the conversion timeout slightly (to around 90–120 seconds) can help during peak load while you tune concurrency.

 

With the above adjustments, you see a significant increase in throughput. Your current rate of roughly 800,000 PDFs per day is consistent with non‑reused processes. With process reuse and the right number of workers, you should be able to push much closer to your 1.5‑million‑per‑day goal. If you need throughput beyond that, scaling out to multiple VMs is the most reliable method.

 

Please review this information on your end and let us know the results.  Kindly get back to us if you need any further assistance in this.

Regards,

Arumugam M