Microservice memory footprints
The various Content Delivery microservices have default Java maximum heap size settings preconfigured in their startup scripts. The actual maximum heap size needed by your microservices depends on the loads placed on them.
The preconfigured maximum heap size reflects the minimal expected memory footprint for each microservice, based on measurements made using Apache JMeter on an AWS (Amazon Web Services) instance using 2 CPUs and 8 GB of RAM.
However, if your services need to process large numbers of requests, these recommended heap sizes may not be sufficient. This is especially true for the Content Service, the Session-enabled Content Service and the Preview Service.
You can use Apache JMeter yourself to generate loads of different sizes, together with server monitoring tools, to capture memory and CPU usage over time.
Once you have determined your ideal heap size, you can change the maximum heap size of each microservice by modifying the -Xmx setting of the JVM options in the microservice's installation script.
| Service name | Initial and minimum heap size (-Xms setting) in MB | Maximum heap size (-Xmx setting) in MB |
|---|---|---|
| Cache Channel Service | 256 | 512 |
| Content Service | 512 | 1536 |
| Context Engine Service | 256 | 512 |
| Contextual Image Delivery | 256 | 512 |
| Deployer | 256 | 512 |
| Combined Deployer | 512 | 1024 |
| Deployer Worker | 512 | 1024 |
| Discovery Service | 128 | 256 |
| Monitoring Agent | 256 | 512 |
| Preview Service | 256 | 384 |
| Session-enabled Content Service | 512 | 1536 |
| UGC Community Service | 256 | 512 |
| UGC Moderation Service | 256 | 512 |