Besides that, why are all these response time numbers multiple of 10, are these rounded up, or is it the precision of the timestamps used to compute these?
The article says the test involved 1000 nodes running 50 containers each, but the conclusion only talks about "no difference between 1st and 30000th container". So we can assume things between 30k and 50k containers didn't go as smoothly? Or did I miss something?
It's a copy error. Initially we tested 30k containers, then later expanded the test to 50k. In both cases Swarm keeps scheduling without breaking a sweat.
I still don't quite get the use case for Swarm right now.
It seems to solve the problem of starting up a bunch of containers across a bunch of hosts, but not anything after that. Maybe the pluggable backends will enable more of the lifecycle management features like restarting containers when a host crashes or handling rolling upgrades.
I think Swarm transparently handles networking and volume management for containers, which can be challenging if your services require multiple containers that run on different hosts and need to talk to each other.
When they say "API response time" I can't tell if that's some service API that rests in Docker itself or if it's the Docker API. Can anyone clarify? I also haven't had my coffee this morning.
Readit News
Deleted Comment
Deleted Comment
It seems to solve the problem of starting up a bunch of containers across a bunch of hosts, but not anything after that. Maybe the pluggable backends will enable more of the lifecycle management features like restarting containers when a host crashes or handling rolling upgrades.