5 ms·

Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.

takeda 8y ago
- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)
- Go0the0gophers 8y ago
  Lol, I let you use java spring boot technology. It is really bloat (ram, cpu, disk, infamous slowly startup and jit optimization, complex tuning eg. thread pool and so on). Good luck.
- yetanotherme 8y ago
  True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.
  - penagwin 8y ago
    This works and helps with storage/transit. Word of warning though that many AV like to flag UPX'd executables (only important if it's not an internal tool), and it'll take even longer for it to start, and will use more memory. My understanding is it essentially does standard compression on the executable and appends the decompression part on the front of it.
  - xyproto 8y ago
    With UPX the entire docker image with Algernon takes only 9MB.
TickleSteve 8y ago
You have to ask yourself what is that space used for?? They're all compiled languages doing (roughly) the same operations. There is an order of magnitude difference in the number of instructions in one compared to the other. Apache is more likely to be entirely cached whereas the others aren't. Size matters for performance.... if you're not CPU bound, fine, but to say its immaterial is naive.
xg15 8y ago
Even if we don't know which particular problem it might cause right now, being wasteful when you can avoid it is never a good idea. Image size is currently not the most important metric, but - guessing how your average node.js package already looks today - demanding people ignore it completely will probably set you on the road of multi TB images that also contain the developer's favorite desktop environment in the medium future.

- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)

Go0the0gophers 8y ago
Lol, I let you use java spring boot technology. It is really bloat (ram, cpu, disk, infamous slowly startup and jit optimization, complex tuning eg. thread pool and so on). Good luck.
yetanotherme 8y ago
True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.
- penagwin 8y ago
  This works and helps with storage/transit. Word of warning though that many AV like to flag UPX'd executables (only important if it's not an internal tool), and it'll take even longer for it to start, and will use more memory. My understanding is it essentially does standard compression on the executable and appends the decompression part on the front of it.
- xyproto 8y ago
  With UPX the entire docker image with Algernon takes only 9MB.

TickleSteve 8y ago

You have to ask yourself what is that space used for?? They're all compiled languages doing (roughly) the same operations. There is an order of magnitude difference in the number of instructions in one compared to the other. Apache is more likely to be entirely cached whereas the others aren't. Size matters for performance.... if you're not CPU bound, fine, but to say its immaterial is naive.

xg15 8y ago

Even if we don't know which particular problem it might cause right now, being wasteful when you can avoid it is never a good idea. Image size is currently not the most important metric, but - guessing how your average node.js package already looks today - demanding people ignore it completely will probably set you on the road of multi TB images that also contain the developer's favorite desktop environment in the medium future.