Fix MongoDB container excessive CPU usage

[digital88]

This fixes #1145

@CodingCanuck can you please try this? My cpu usage became reasonable. I upped HC retry to 5s and made sure we first check replica set status with rs.status() (mongo docs says it throws if no rs was initiated) before rs.initiate(). For mongo v4 and below I kept previous healthcheck command.

Also, had to touch .prettierrc and test-helper.ts because I'm on Windows and \n just breaks everything here :)

[netlify]

✅ Deploy Preview for testcontainers-node ready!

Name	Link
🔨 Latest commit	b445d58
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-node/deploys/68d55f2792b42f0008d683e0
😎 Deploy Preview	https://deploy-preview-1146--testcontainers-node.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[CodingCanuck]

@CodingCanuck can you please try this? My cpu usage became reasonable.

This reduces CPU usage for me, woo hoo! Sample output of docker stats (in a test described here), after this PR:

px vitest run packages/modules/mongodb/src/mongodb-container.test.ts -t "should have low CPU usage" --silent=false |& grep "======" | grep -v "testcontainers-"
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======4bdebaedb613   upbeat_cori                        1.60%     129.2MiB / 7.654GiB   1.65%     956B / 126B     0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======4bdebaedb613   upbeat_cori                        2.42%     128.7MiB / 7.654GiB   1.64%     956B / 126B     0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======4bdebaedb613   upbeat_cori                        28.85%    128.7MiB / 7.654GiB   1.64%     956B / 126B     0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======4bdebaedb613   upbeat_cori                        1.60%     129.1MiB / 7.654GiB   1.65%     956B / 126B     0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======4bdebaedb613   upbeat_cori                        2.25%     128.6MiB / 7.654GiB   1.64%     956B / 126B     0B / 1.03MB   76
======

Compare with before this PR:

npx vitest run packages/modules/mongodb/src/mongodb-container.test.ts -t "should have low CPU usage" --silent=false |& grep "======" | grep -v "testcontainers-"
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======ebd939aa0cc6   sleepy_feynman                     54.51%    122.9MiB / 7.654GiB   1.57%     1.11kB / 126B   0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======ebd939aa0cc6   sleepy_feynman                     56.75%    122.7MiB / 7.654GiB   1.57%     1.11kB / 126B   0B / 1.02MB   76
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======ebd939aa0cc6   sleepy_feynman                     45.73%    258.7MiB / 7.654GiB   3.30%     1.11kB / 126B   0B / 1.02MB   88
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======ebd939aa0cc6   sleepy_feynman                     45.73%    181MiB / 7.654GiB     2.31%     1.11kB / 126B   0B / 1.02MB   83
======
======CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
======ebd939aa0cc6   sleepy_feynman                     50.80%    122.6MiB / 7.654GiB   1.56%     1.11kB / 126B   0B / 1.03MB   76
======

[CodingCanuck]

@digital88 any thoughts on what sort of regression test could've caught this?

I have no design ideas here, but I figure the question could be productive to ask.

(And thanks so much for your light-speed fix for this issue!)

[digital88]

@digital88 any thoughts on what sort of regression test could've caught this?

I have no design ideas here, but I figure the question could be productive to ask.

(And thanks so much for your light-speed fix for this issue!)

Good to hear it's mitigated!

Probably something like your test example, but this problem is also tied to mongo TC implementation. Because TC supported mongo with mandatory replica set, I had to keep this implementation working when I added user+password auth. Didn't catch that low retry interval would make it constantly re-create rs and consume CPU.

As side note I still think replica set initialization should be separate method on started mongo container, not something that is forced by default when starting container.

[cristianrgreco]

Hi @digital88, thanks for the fix!

Are there any other changes you want to make or we're good to merge? A test would've been nice but I also don't see how we can test that container CPU utilisation is "reasonable", consistently across multiple machines

[digital88]

Hi @digital88, thanks for the fix!

Are there any other changes you want to make or we're good to merge? A test would've been nice but I also don't see how we can test that container CPU utilisation is "reasonable", consistently across multiple machines

Yes, I think we are good to merge, @CodingCanuck confirmed it's fixed.

I'm too not sure how even to begin approach this regression with tests. We somehow need to benchmark external service (docker or podman) while running our code.

[CodingCanuck]

Hi @digital88, thanks for the fix!
Are there any other changes you want to make or we're good to merge? A test would've been nice but I also don't see how we can test that container CPU utilisation is "reasonable", consistently across multiple machines

I completely agree: I can't imagine a pass/fail "unit"-style test that would be productive here.

I'm too not sure how even to begin approach this regression with tests. We somehow need to benchmark external service (docker or podman) while running our code.

I can't imagine regression / correctness tests, but I can imagine performance tests that generally tracks cost / compute changes across PRs. Changes in cost from any given PR can then be optionally investigated, but higher CPU doesn't necessarily mean worse (since most new features will consume some CPU). I'd imagine an auto-generated report that could be attached to each PR, saying "this increased CPU by X% in benchmark case Y", and the PR reviewer could decide whether that's desired / expected.

I'm not familiar with the testcontainers repo and I don't know what priorities it has, but note that the XZ Utils backdoor that made news cycles last year was caught by having a performance testing suite: https://en.wikipedia.org/wiki/XZ_Utils_backdoor#Background

Freund noticed that SSH connections were generating an unexpectedly high amount of CPU usage [...] Freund reported his finding to Openwall Project's open source security mailing list, which brought it to the attention of various software vendors.

So I'd consider this as a completely different issue that's way out of scope for this particular regression, but the only recommendation I could think of making here is cross-product performance/CPU tests, where you can optionally investigate spikes in CPU consumption. (And without knowing testcontainers well, I'd guess that it's likely not worth the effort if you don't see this kind of regression often)