6 ms·
Uses alpine images for small footprint That's really become a docker meme. Please be aware you're sacrificing performance due to not using glibc.
by mkesper 7y ago
Uses alpine images for small footprint
That's really become a docker meme. Please be aware you're sacrificing performance due to not using glibc.
- kjeetgill 7y agoI hadn't heard this before, also sold by small image sizes. What is the big performance weakness of mscl vs glibc? Anything beyond binary size vs shared pages?
- the8472 7y agoglibc has thread-local pools for malloc, afaik musl uses locks.
- arcticfox 7y agoI'm very weak when it comes to stuff at this level but this sounds like it might be something I really want to know. If I want to run Python or Ruby, what is the practical downside to Alpine? Am I understanding correctly that Python or Ruby interpreters built to run on Alpine use musl instead of glibc, and that might have very noticeable performance impacts? This thread is opening my eyes, I kind of assumed as long as I was running the right version of those interpreters, I was getting more or less the same thing. That feels like a very bad assumption now.
- capableweb 7y agoAs always when it comes to performance, you should measure the difference yourself and see if it's a switch worth doing for your use case. "very noticeable performance impacts" depends so much on the context that it's hard to answer in a general way.
- jiux 7y ago> also sold by small image sizes. Out of curiosity, what sold you on this? Has caching of a docker image been considered in this conclusion as well?
- kjeetgill 7y agoI was just a casual local user, and didn't have any production use of it. At the time, if my memory serves, images easily got into many GB locally. This was before Ubuntu and others had produced smaller official images of their own.
- jordinl 7y agoPerformance of what? Building an image?
- cyphar 7y agoRuntime performance. Musl has different performance characteristics to glibc (glibc uses thread-local pools for malloc, while musl uses locks).
- atomi 7y ago> Starting with 1.1.9, musl’s dlerror state is thread-local and now matches the glibc behavior. https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc...
- NieDzejkob 7y agodlerror is entirely irrelevant here.
- atomi 7y agoIn terms of what? Performance? Musl is more correct. Most people aren't serving Google or Facebook levels of requests. My only issue is with people choosing software purely based on performance.
- NieDzejkob 7y agoNo, it's just that dlerror and malloc are two different functions.
- atomi 7y agoI think that's self-evident, thank you.
- ImJasonH 7y agoSince it's not using a multi-stage build, go dev tools are clogging up the image, losing the benefit of using alpine in the first place. https://link.medium.com/S2z0PtVHQ1 https://link.medium.com/S2z0PtVHQ1 If you're just running a go binary you can use distroless as the base for even smaller images.
- karlkeefer 7y agoThanks for linking this. Will implement. Also like the "tags" within the dockerfile for dev and prod - much cleaner than the multi-file solution currently in the repo.
- mattacular 7y agoFootprint (ie. of the built container image which must be transferred back and forth to repos) and runtime performance are two different things you may care to optimize differently or not.
- sidlls 7y agoAlpine has problems with its network stack that make it unsuitable for use in some contexts.
- karlkeefer 7y agoThanks - will update the prod recipe. I saved hundreds of MB on the front-end images switching to alpine so I want a little alpine crazy :)
- zapita 7y agomusl libc has been robust and fast in my experience. What performance issues have you encountered?