5 ms·

I would really love it if there was a benchmark around running VMs and containers for something like this. Our dev/test system is all docker containers so that

I would really love it if there was a benchmark around running VMs and containers for something like this. Our dev/test system is all docker containers so that is what we would care about. I guess it would be hard as there are to many ways to scale out what you run - how many VMs, how many containers, what are you running in them? It would be an interesting benchmark matrix to sort for. It would be interesting just to see how many containers you could start, run lighttpd and each server a static web page? Maybe 1/2 with the page and 1/2 with an application that builds the page? Who knows...to many variables. I think we will just by a system when we can and try our workload on it. Oh, well.

chrisseaton 9y ago
I don't think running processes inside a container will be any more interesting for benchmarking than just running the processes normally. What overhead does a container add? A little indirection in syscalls? I would imagine the number of instructions involved in that are beyond trivial for serving a page, so I can't see how benchmarking running containers would be different than just benchmarking running your processes. VMs - now with processor virtualisation technology I'm sure the different processor architectures do make an interesting difference there.
- myrandomcomment 9y ago
  In some of our scaling test where each container had an IP connecting out to a remote system we ran in to a ton of issues at scale that we did not see running the same number of processes on the bare metal. The overhead of the namespace can add up.
  - nwmcsween 9y ago
    This is due to the what the container orchestratior uses to route traffic, check out project calico for low overhead networking.
    - myrandomcomment 9y ago
      The issue had everything to do with how Linux handles networking when you have 1000 container interfaces on a single system. Tweaking net.ipv4.neigh.default.gc* solved most of the issues. I am familiar with Calico and it would not have solved it.
jdubs 9y ago
This may be interesting to you. http://www.brendangregg.com/blog/2017-05-15/container-performance-analysis-dockercon-2017.html http://www.brendangregg.com/blog/2017-05-15/container-perfor...
- myrandomcomment 9y ago
  Thank you!

chrisseaton 9y ago

I don't think running processes inside a container will be any more interesting for benchmarking than just running the processes normally. What overhead does a container add? A little indirection in syscalls? I would imagine the number of instructions involved in that are beyond trivial for serving a page, so I can't see how benchmarking running containers would be different than just benchmarking running your processes. VMs - now with processor virtualisation technology I'm sure the different processor architectures do make an interesting difference there.

myrandomcomment 9y ago
In some of our scaling test where each container had an IP connecting out to a remote system we ran in to a ton of issues at scale that we did not see running the same number of processes on the bare metal. The overhead of the namespace can add up.
- nwmcsween 9y ago
  This is due to the what the container orchestratior uses to route traffic, check out project calico for low overhead networking.
  - myrandomcomment 9y ago
    The issue had everything to do with how Linux handles networking when you have 1000 container interfaces on a single system. Tweaking net.ipv4.neigh.default.gc* solved most of the issues. I am familiar with Calico and it would not have solved it.

jdubs 9y ago

This may be interesting to you. http://www.brendangregg.com/blog/2017-05-15/container-performance-analysis-dockercon-2017.html http://www.brendangregg.com/blog/2017-05-15/container-perfor...

myrandomcomment 9y ago
Thank you!