Files
gotenberg/build/docs/content/12-scalability.md
2019-10-01 09:33:31 +02:00

55 lines
1.6 KiB
Markdown

---
title: Scalability
---
Google Chrome and unoconv (LibreOffice) are intricate programs.
Gotenberg tries to abstract as much complexity as possible but it can
only do it to a certain extend.
For instance, Google Chrome misbehaves if there are too many concurrent conversions.
That's why for [HTML](#html), [URL](#url) and [Markdown](#markdown) conversions, the API does only 6 conversions in parallel.
The more concurrent requests, the more `504` HTTP codes the API will return.
On another hand, for [Office](#office) conversions, the API will start as many unoconv (LibreOffice) instances as there are
requests. The limitation here is the available memory.
> See our [load testing use case](../loadtesting) for more details about the API behaviour under heavy load.
## Strategies
### Increase timeout
This strategy is mostly for [HTML](#html), [URL](#url) and [Markdown](#markdown) conversions.
You may increase the conversion timeout. In other words, you accept that a conversion takes more time
if there are more than 6 conversions in parallel.
> See [timeout section](#timeout).
### Scaling
The API being stateless, you may scale it as much as you want.
For instance, using the following Docker Compose file:
```yaml
version: '3'
services:
# your others services
gotenberg:
image: thecodingmachine/gotenberg:6
```
You may now launch your services using:
```bash
$ docker-compose up --scale gotenberg=your_number_of_instances
```
When requesting the Gotenberg service with your client(s), Docker will automatically
redirect a request to a Gotenberg container according to the round-robin strategy.