Parallel request handling in the latest version

[edkarhuber]

Hello,

I want to clarify if the latest version can handle requests in parallel and what to expect from it in this regard.

Consider this scenario:
There is 1 instance and we send 5 parallel (simultaneous) requests. Let's say the processing time for each is 1 minute.
Is it correct that all requests will go into one internal queue and finish sequentially one after another. Then the total time to process all will be 5 minutes. Is this correct?
Is there a way to configure this single instance to handle multiple requests in parallel?

I'm asking because after updating from version 7 to 8, some performance tests have fallen.
In version 7, PDFs seemed to generate in parallel, but in version 8, it appears that each request depends on the previous one.

[gulien]

Gotenberg version 7.10.0 introduced a long-running Chromium process. From the release note:

---

There were memory leaks due to defunct processes. As each conversion was starting a Chromium process, it was adding up quickly overtime. Alas, the issue is still upstream and it is recommended to have a long-running browser to handle conversions.

⚠️ There is now a single Chromium browser that handles all conversions. It manages them one by one, like the LibreOffice process in stateful mode. Under heavy load, you should consider increasing the number of Gotenberg instance.

Please note that this only mitigates the memory leaks; according to your metrics, consider restarting your Gotenberg instances from time to time.

New flags:

• --chromium-restart-after - Number of conversions after which Chromium will automatically restart. Set to 0 to disable this feature (default 0).
• --chromium-auto-start - Automatically launch Chromium upon initialization if set to true; otherwise, Chromium will start at the time of the first conversion (default false).
• --chromium-start-timeout - Maximum duration to wait for Chromium to start or restart (default 10s).

New metrics:

• chromium_requests_queue_size - Current number of Chromium conversion requests waiting to be treated.
• chromium_restarts_count - Current number of Chromium restarts.

Fixes #642 - thanks @petternordlanderhelo & @JulienWeintraub!

[gulien]

There is everything here:

There is now a single Chromium browser that handles all conversions. It manages them one by one, like the LibreOffice process in stateful mode. Under heavy load, you should consider increasing the number of Gotenberg instance.

TL;DR: if you want parallel conversions, increase the number of Gotenberg instances. Previously X conversions = X Chromium browsers in one Gotenberg instance, which is no more the case.

[edkarhuber]

Thanks for making it clear.
It would be cool to have this as a configurable option. It's hard to imagine a scaling policy where the number of instances equals the average number of requests per second, so as not to make users block each other.

[gulien]

You’d prefer « infinite » browsers instances until you have no more CPU/memory available?

It's hard to imagine a scaling policy where the number of instances equals the average number of requests per second, so as not to make users block each other.

Because it is a bad scaling strategy.

A single instance can handle concurrent requests, it’s just that the average response time may be higher according to the load.

If your use case requires to handle a LOT of concurrent requests, good news, just spin up more instances, it’s cheap.

[edkarhuber]

You’d prefer « infinite » browsers instances until you have no more CPU/memory available?

I would prefer to configure the pool size of available browsers that are in rotation to handle concurrent requests

[gulien]

You'd get the same result as handling the pool size of Gotenberg instances 😄