Kent O. Johnson wrote:Ian and Aiden,
Does your book cover performance tuning or considerations of Docker Containers? I see production concerns in chapters 11 and 12 and am pleased to see a chapter on security. I have used the "docker stats" command to watch performance at the CLI and Shipyard. I have also used memory config props in the docker-compose.yml files. Do you go in depth on production performance tuning?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Kent O. Johnson wrote:Regarding database I/O performance, I had an issue where using a PostgreSQL database container with volumes from a data-only container from within a VM gave very unpredictable and erratic I/O behavior, which I am thinking is because of multiple layers of swapping between the physical machine and the virtual machine. I was using volumes so I am thinking the problem was not a container problem at all, just the configuration of the I/O driver for VMWare, the hypervisor I used.
Switching everything to physical machines outside of containers made things much faster and more consistent. I considered trying using containers on the physical machine though I hadn't got to that yet. I am glad you mentioned the different storage drivers, that they can affect performance, though it sounds like they are only relevant for in-container I/O. Is that right? If I wanted to run a PostgreSQL database container or any database container without mounting volumes then how would I go about achieving similar performance to using the DBMS on bare metal?
Using databases inside of containers seems to unnecessarily complicate backups since there is no SSHing into a container, though I could see an automated backup running to a directory mounted as a volume to solve that problem. Would you solve the backup use case like that?
Regarding network I/O, do you find that the virtual network device layer used by the Docker Engine adds significant enough overhead to warrant bypassing it all together with the "--net=host" option? How much of a performance gain have you seen that give? This is the first time I have seen that option and would like to learn more about it and where it would make sense.
Kent
Aidan Hobson Sayers wrote:
I'll briefly note the how each one works below:
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |