
Benchmarking Debian vs. Alpine as a base Docker image (2018) - aloukissas
https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine-as-a-base-docker-image
======
thedance
If you're actually sensitive to performance you surely would never use
upstream debian binary packages. At least for the x86_64 distro they are built
to run on Opteron and just rebuilding them for a less-old CPU like Intel Sandy
Bridge, or for whatever CPU you intend to use, can make a huge difference. I
get a full 100% improvement in sysbench oltp just from rebuilding the libc and
database server with march=skylake.

~~~
michaelmrose
Benchmarks please. I also do not think that they are actually tuned
specifically for opteron.

~~~
thedance
Why would you care what my benchmarks look like? If you are performance-
sensitive, run yours. If you don’t have any, you’re not sensitive to
performance.

~~~
jasongill
I think the only one being sensitive here is you - the other commenter is just
looking for some way to quantify the huge performance gain that you claim, as
it seems unlikely (although not impossible) that just recompiling the packages
would provide such a major performance increase.

~~~
thedance
Using the oltp workload that comes packaged with sysbench, the median latency
falls from 50us to 25us on a skylake xeon with nvme storage after recompiling
MySQL and libc with march=skylake. Give it a whirl.

------
wwarner
If you read the comments, it looks like the meaningful difference btw the two
distros is (was?) the libc implementation. Alpine uses the newer, smaller
musl, while debian used the battle hardened glibc.

------
amanzi
If you're interested in Docker best practices for Python specifically, I
highly recommend the following site:
[https://pythonspeed.com/docker/](https://pythonspeed.com/docker/)

I listened to the author on The Python Podcast and learned lots from the
discussion, in particular the differences between Alpine and Debian for Python
images.

------
clarkdave
We used to use alpine because it was smaller (ferrying images in and out of
AWS adds up) and the package management UX often felt better (the community
and testing repos tend to make many things easily available, which led to
simpler and easier to follow Dockerfiles).

Eventually we switched to Debian-based images because of intermittent DNS-
related woes that plagued our alpine containers. We struggled to isolate the
cause but it seemed to be a combination of Node + Consul DNS. Suddenly those
saved gigabytes and smaller Dockerfiles didn’t seem worth the hassle; after
jumping to Debian we never saw that issue, nor anything similar.

------
hprotagonist
The only things i regularly use docker for require wacky cmake configuration
and heavy reliance on specific compiler toolchains and GPU stuff, not to
mention scientific-stack python wheels that I don't want to rebuild for musl.

I don't see a switch to alpine for my normal use case happening any time soon,
but I'm glad it's available as a lightweight option for the times when my
normal workflow isn't a requirement.

------
rahimnathwani
Interesting comments about the same topic recently:

[https://news.ycombinator.com/item?id=22182226](https://news.ycombinator.com/item?id=22182226)

~~~
itamarst
That was mostly about image build time (and it's pretty Python specific), this
article is more about runtime performance.

~~~
rcarmo
Actually, I have a few notes on image performance in there:

[https://news.ycombinator.com/item?id=22185760](https://news.ycombinator.com/item?id=22185760)

(I maintain both Ubuntu and Alpine images and never noticed significant
performance differences)

------
throwawaynothx
The article even states it's only 1 select statement.

~~~
mst
Though honestly a web endpoint performing 1 select statement per request is a
lot closer to reality than 10,000.

Does make it a little inconclusive though.

------
87zuhjkas
Why pyhton 2.7? He's dead, Jim.

------
oarsinsync
Article is from 2018.

