Container-to-Container Communication
miketheman.net
miketheman.net
Firstly you are creating a hard dependency for having the two services sharing a same box, with a shared file system (that's difficult to coordinate and secure.) But also should you add a new service that also want to connect via unix socket, stuff could get tricky to orchestrate.
But this also limits your ability to move stuff about, should you need it.
Inside a container, I think its probably a perfectly legitimate way to do IPC. Between containers, I suspect you are asking for trouble.
I did enjoy the work overall, incl Graviton comparison. Likewise, OS X's painfully slow Docker impl has driven me to Windows w/ WSL2 -> Ubuntu + nvidia-docker, which has been night and day, so not as surprised that those numbers are weird.
In my example, I'm using an unmodified gunicorn runner to load the uvloop worker. So I'm still only using a single worker process. Once I start tweaking the `--workers` count, I get a much higher queries per second.
And you're correct - this is a narrow benchmark, not designed to test total TPS or saturate resources.
Interesting wrt workers -- how does TCP vs sockets start looking in a multiple worker + multicore scenario, esp. wrt peak QPS? That's more confusing for schedulers :) Also, FWIW, the GIL thing might even be true in the case of single core <> single vs multiple workers. Docker supports pinning (`cpuset`?), so should be pretty doable..
We actually have a fairly similar production setup, so up to GPUs confusing things, have been curious on how deep to look in upcoming scaling work.
As a fun extra wrinkle, we also used to have nginx as a poor man's api gateway: `request -> [ nginx_container -[tcp]-> app_container1 -[tcp]-> nginx_container -[tcp]-> app_container2 -[tcp]-> ... ]`, but had enough quality issues that we removed the internal nginx indirections.
I use it instead of Google's own ingress because it gives you better control over load balancing and can react faster to deployments.
> By definition, all containers in the same Podman pod share the same network namespace. Therefore, the containers will share the IP Address, MAC Addresses and port mappings. You can always communicate between containers in the same pod, using localhost.
I'm a noob here but why wouldn't you use IPC?
https://docs.podman.io/en/latest/markdown/podman-run.1.html#...
I can see, from a design perspective, that network namespacing is likely more scalable. Network addresses can be local or WAN while unix sockets would tie you to a single node. That implies a very different and slightly more rigid scaling strategy with IPC based communication.
The overhead for that alone would outstrip any benefits.
It's lower lever than OP but might give ideas.
The results when running on other machines could be impacted by a number of different factors. Almost impossible to know what is limiting performance without deep diving into the logs
Of course this also requires some discipline from the user, like not running containers as root, and not running containers with Docker socket access (which is as good as having root).