I have two containers built from the same Dockerfile and doing the same WebDAV job, with different ports, user IDs, and storage paths. A simple directory refresh returns successfully from both, but one takes milliseconds while the other takes about five seconds and briefly shows much higher CPU usage. What should I check first?
Why would two identical Docker containers handle the same request so differently?
Asked by
+Zindle8
Answers
First, separate the measurement from the diagnosis. Docker's CPU percentage is a snapshot over an interval, not a direct measure of how much work a request needs. Repeat the same request several times against each container, alternate the order, and compare response times and CPU over a longer window. A single refresh can catch startup work, a busy host, or timing noise.
If the gap persists, compare the actual runtime settings rather than only the Dockerfile: mounts, permissions, environment, user and group IDs, and the files visible at each storage path. Also check whether one directory has many more entries or unusual files. Those differences can make a directory listing much more expensive even when the request is the same.
Reply to this answer
I'd look closely at the storage paths and mount types. The containers may be configured similarly but still be traversing different directories, filesystem layers, or network mounts. Check the host paths behind each bind mount, directory size and file count, and whether either path has permission checks or slow storage involved.
A five-second response is a useful clue. Check access and error logs, and time the request from the client with each endpoint tested directly. That can help distinguish slow directory traversal from a proxy, DNS, or network delay.
Reply to this answer
Make sure the two tests really reach the intended containers. Try each endpoint directly, bypassing any proxy or load balancing, and verify the response headers and server logs. A proxy route, extra authentication step, or different connection behavior could explain the latency without the containers themselves doing different work.
Reply to this answer
Check the UID and GID changes before assuming they are harmless. The process may have different access to the mounted directory, and a permission problem can lead to repeated checks or errors. Compare the effective user inside each container and inspect the logs while making the request.
Resource limits are useful to prevent a process from taking too much CPU or memory, but they won't explain why one request is slow. I would treat limits as containment, then find the cause with repeatable tests and logs.
T!+Buckle:
That makes sense. I will check effective users and permissions, and use limits only as a safeguard rather than as the fix.
Reply to this answer
Add your answer
Answers are reviewed before publication.
M6~Sundry:
Both containers are on the same host, and I used the same refresh request. I will repeat the test in alternating order and compare the mounted directories.