dotCMS is a Java web application, and to achieve acceptable performance all Java web applications must meet minimum requirements for CPU, memory and networking. When running dotCMS in Docker, please review the following sections and ensure that Docker is configured properly to minimize performance issues.
The environment that dotCMS runs in should have 100% guaranteed (reserved) access to the CPU resources allocated to it. CPU oversubscription can cause severe performance problems for all workloads on the server due to Java garbage collection dynamics.
For more information on the Docker CPU allocation parameters, please see the Docker documentation.
The environment that dotCMS runs in should have 100% guaranteed (reserved) access to the memory (RAM) resources allocated to it. Memory oversubscription can cause severe performance problems (including application crashes) for all workloads on the server due to Java garbage collection dynamics.
Important: A swap disk should not be used on any server running dotCMS. This is even more critical in a Docker environment.
For more information on the Docker memory allocation parameters, please see the Docker documentation.
Docker has a number of different options for allocating storage to Docker containers. Unfortunately, many of these introduce overhead and latency to the storage layer which can significantly impact dotCMS performance. Additionally, allocating data storage within the Docker container can introduce significant challenges with dotCMS storage scalability and data lifecycle management & persistence.
The best I/O performance and data management is usually achieved by mounting a host data directory in the dotCMS Docker container to use for database, assets (
ASSET_REAL_PATH), and dotsecure (
DYNAMIC_DATA_PATH) storage. This provides a good separation of concerns between the application managed in the Docker container, and the persistent data managed outside of the Docker container.
For more information on the Docker storage parameters, please see the Docker documentation.
Docker has several different options for managing network connectivity for containers using bridging and/or NAT. These can introduce varying levels of system overhead and network latency, although this is typically unnoticeable in a single-server dotCMS environment. However, dotCMS clustering can be fairly sensitive to network latency, and the NAT port mappings used by some Docker networking models can interfere with proper cluster operation. Running a dotCMS cluster will be challenging to configure properly and might not be possible.
For more information on the Docker networking parameters, please see the Docker documentation.
Running Docker in a Virtual Machine
When running Docker inside of a virtual machine (VM), you must ensure that the appropriate resources are allocated to both the virtual machine and to the dotCMS Docker container. Interaction between the CPU, memory, and network allocation of the VM, the Docker container, and other VMs running on the same host may cause unexpected performance issues which may be difficult to resolve. Specifically, guaranteeing CPU allocation to a Docker container inside a virtual machine may be possible, but requires fine-tuning of both the VM configuration and the Docker runtime parameters.