2

My backend is a nodejs application running in ubuntu linux. It needs to spawn a nodejs sub process when there is a request from client. The sub process usually takes less than 20 seconds to finish. There is a need to manage these processes if there are many concurrent requests come in. I am thinking to move spawn process inside docker container. That means a new docker container will be created to run the process if there is a request from client. In this way, I can use kubernetes to manage these docker containers. I am not sure whether this is a good design. Whether put the process inside docker container cause any performance issue.

The reason I am thinking to use docker container instead of spawn is that kubernetes offers all the features to manage these containers. Such as, auto scale if there are too many requests, limit the cpu and memory of the docker container, scheduler, monitoring, etc. I have to implement these logic if I use spawn.

Joey Yi Zhao
  • 37,514
  • 71
  • 268
  • 523
  • Are you sure you want to spawn a new container on each request? That looks like overhead to me, as starting it could already take some time. What's the need for such a complex setup anyways? Where's the problem in just not spawning anything? – Nico Haase Apr 06 '19 at 10:45
  • I want to manage these processes. If I use docker, kubernetes will offer all manage features for me so I don't need to implement it. – Joey Yi Zhao Apr 06 '19 at 10:48
  • What do you mean by "manage"? Why not run request **without** spawning everything? If the subrequest finishes, won't the spawned process terminate? – Nico Haase Apr 06 '19 at 10:48
  • I have updated my question. `manage` means limit cpu/memory resources to be used by the sub-process, auto-scale if there are too many requests, etc. – Joey Yi Zhao Apr 06 '19 at 10:50

3 Answers3

2

You can easily measure the overhead yourself: get any basic docker image (e.g. a Debian base image) and run

time bash -c true
time docker run debian bash -c true

(Run each a few times and ignore the first runs.)

This will give you the startup and cleanup costs. During actual runtime, there is negligible/no further overhead.

Kubernetes itself may add some more overhead - best measure that too.

AnoE
  • 8,048
  • 1
  • 21
  • 36
2

From the Docker documentation on network settings:

Compared to the default bridge mode, the host mode gives significantly better networking performance since it uses the host’s native networking stack whereas the bridge has to go through one level of virtualization through the docker daemon. It is recommended to run containers in this mode when their networking performance is critical, for example, a production Load Balancer or a High Performance Web Server.

So, answers which say there is no significant performance difference are incorrect as the Docker docs themselves say there is.

This is just in the case of network. There may or may not be impacts in accessing disk, memory, CPU, or other kernel resources. I'm not an export on Docker, but there are other good answers to this question around, for example here, and blogs detailing Docker-specific performance issues.

Ultimately, it will depend on exactly what your application does as to how it is impacted. The best advice will always be that, if you're highly concerned about performance, you should set your own benchmarks and do your own testing in your environment. That doesn't answer your question because there is no generic answer. Importantly, though, "there's virtually no impact" does not appear to be correct.

Graham Lea
  • 5,797
  • 3
  • 40
  • 55
1

docker is in fact just wrapper on core functionaity of linux itself so there is no significant impact - it is just separaing process in container. so question is more about levels of virtualisation in your host. If it is linux in windows, or docker on windows it can affect your app somehow and virtualisation is a heavy way then. docker let you separate dependencies without almost any impact on performance.

Michał Brzeziński
  • 11
  • 5