3 ms·

In terms of what? Boot times?

by rany_ 2y ago

frankjr 2y ago
Musl's memory allocator is (was?) subpar compared to glibc's, especially in multi threading contexts. https://news.ycombinator.com/item?id=23080290 https://news.ycombinator.com/item?id=23080290
- rwaksmunski 2y ago
  It's a bit better now, but still nowhere near FreeBSD's jemalloc.
_joel 2y ago
Usage, I converted a bunch of containers to it from debian-slim in our fairly large CI/CD setup and it processed workloads noticably slower, despite booting slightly quicker as it's a smaller pull. However, with network speeds nowadays, it was negligible difference and not worth it. Rolled it back to debian-slim.
- cduzz 2y ago
  Would these performance concerns be an issue if you were using alpine "on the metal" and debian containers? When running complex applications I find it's simplest to "compile" the application into a container thus rendering some tedious complex runtime to a static binary that's trivial to run without worrying about tedious dependency management. It burns a bit of storage but that's not a big deal these days. If someone suggested to me "hey I want to run a big PHP / nginx / mysql workload for my startup; should I use alpine?" I'd suggest they find a doctor.
  - _joel 2y ago
    We're providing a CI/CD system that supports several different departments and teams with varying technology in their stack and a plethora of different pipelines. Some big java projects, python and loads of other batch jobs like spark etc. If only it was as simple as just running it on bare metal. The issue is with muslc, not the hardware.
    - cduzz 2y ago
      I am pretty comfortable with suggesting one OS as the "hardware" OS and another OS for the userland... Alpine's design makes it really well suited to "hardware"; I'd even suggest it's probably a good way to run kubernetes or lxd because it's simple and trivial to provision/customize and not full of vendor nonsense. You can use alpine as a "base container" layer, but you'll quickly end up in a world where libc vs musl or "I need a weird package" makes a tiny centos/debian container more appealing. If you've got java or python or ruby or some other complex runtime, just run it in the most commonly used base container and don't go looking for trouble...

In terms of what? Boot times?

by rany_ 2y ago

In terms of what? Boot times?

Musl's memory allocator is (was?) subpar compared to glibc's, especially in multi threading contexts. https://news.ycombinator.com/item?id=23080290 https://news.ycombinator.com/item?id=23080290

rwaksmunski 2y ago
It's a bit better now, but still nowhere near FreeBSD's jemalloc.

_joel 2y ago

Usage, I converted a bunch of containers to it from debian-slim in our fairly large CI/CD setup and it processed workloads noticably slower, despite booting slightly quicker as it's a smaller pull. However, with network speeds nowadays, it was negligible difference and not worth it. Rolled it back to debian-slim.

cduzz 2y ago
Would these performance concerns be an issue if you were using alpine "on the metal" and debian containers? When running complex applications I find it's simplest to "compile" the application into a container thus rendering some tedious complex runtime to a static binary that's trivial to run without worrying about tedious dependency management. It burns a bit of storage but that's not a big deal these days. If someone suggested to me "hey I want to run a big PHP / nginx / mysql workload for my startup; should I use alpine?" I'd suggest they find a doctor.
- _joel 2y ago
  We're providing a CI/CD system that supports several different departments and teams with varying technology in their stack and a plethora of different pipelines. Some big java projects, python and loads of other batch jobs like spark etc. If only it was as simple as just running it on bare metal. The issue is with muslc, not the hardware.
  - cduzz 2y ago
    I am pretty comfortable with suggesting one OS as the "hardware" OS and another OS for the userland... Alpine's design makes it really well suited to "hardware"; I'd even suggest it's probably a good way to run kubernetes or lxd because it's simple and trivial to provision/customize and not full of vendor nonsense. You can use alpine as a "base container" layer, but you'll quickly end up in a world where libc vs musl or "I need a weird package" makes a tiny centos/debian container more appealing. If you've got java or python or ruby or some other complex runtime, just run it in the most commonly used base container and don't go looking for trouble...