Organizer Sizing
The minimum recommended sizing of Output organizer services are as follows:
| Purpose | Replicas | Resource requests | Resource limits | |
|---|---|---|---|---|
| organizer | Back- and frontend to handle collections | 1 | memory: 0.5Gi, cpu: 100m, ephemeral-storage: 1Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi |
| viewer | Document viewer | 1 | memory: 1Gi, cpu: 200m | memory: 4Gi, cpu: 2000m |
| controller | Execution engine for export jobs | 1 | memory: 0.5Gi, cpu: 100m | memory: 1Gi, cpu: 1000m |
| worker-topdf | Export functionality | 1 | memory: 1Gi, cpu: 200m | memory: 4Gi, cpu: 2000m |
Sizing recommendations for production
These recommendations refer to approximately 500 users. A ramp-up accompanied by thorough monitoring is strongly recommended to tune the settings according to your specific needs.
| Purpose | Replicas | Resource requests | Resource limits | |
|---|---|---|---|---|
| organizer | Back- and frontend to handle collections | max(n/4, 2) | memory: 2Gi, cpu: 1000m, ephemeral-storage: 10Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 10Gi |
| viewer | Document viewer | max(n, 2) | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi |
| controller | Execution engine for export jobs | 1 | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi |
| worker-topdf | Export functionality | max(n/4, 2) | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi |
n is a scaling factor, which means in this context you need approximately one instance of organizer for four instances of jwt. All instances should have at least a scaling of two, to be resistant to unexpected failures.
Database Sizing
For general information about resource management in container environments please see: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ Please also advice the documentation of your chosen database for more accurate recommendations.
Persistent Memory
The exact sizing of the database is difficult to predict, because it heavily depends on the number of collections created, how many changes will be persisted in the history and how regularly the database will be cleaned up by deleting old collections or versions.
We recommend for a test installation no less than 250Mb of storage. From our experience the space requirements in bigger production environments can rise up to 500GB per year, without deleting anything.
It is always good to monitor the database and adjust the space requirements if needed.
Memory
In contrast to persistent storage the required memory depends heavily on the amount of users that use the system simultaneously.
We recommend at least 250Mi of reserved memory to start with.
If the memory is not sufficient, the system will not fail immediately, but the performance will be heavily impacted, so also keep an eye out of the usage and adjust accordingly.
CPU
Same as the memory the CPU usage depends on the number of users working simultaneously.
We recommend at least 100m reserved CPU in a container environment.
Also with the CPU limits it is always recommended to monitor and adjust the limits as needed. We suggest not to go above 33% average CPU usage.