4 ms·

I did benchmark it against nginx and found Caddy to be 5-7x times slower, but like all benchmarks go...results are subject to ones requirements (or mistakes).

by melx 3y ago

I did benchmark it against nginx and found Caddy to be 5-7x times slower, but like all benchmarks go...results are subject to ones requirements (or mistakes). What got me away from using it: - the directives feel intuitive but as soon as I needed a complex config it all became a chain of very implicit strings - the caddy author(s) decided few years ago to add custom http header with their sponsors[0]. That header could not be removed, it's no longer present in current Caddy but the bad taste still remains. [0] https://news.ycombinator.com/item?id=15238315 https://news.ycombinator.com/item?id=15238315

j-a-a-p 3y ago
> it's no longer present in current Caddy but the bad taste still remains Adding a sponsor header is harmless (albeit useless IMO). For me that would be no reason to not choosing this software, and certainly no ground for having a 'bad taste'.
- rekoil 3y ago
  What purpose does it actually fulfil? Who is actually looking at individual HTTP requests like this? All it does is take up extra traffic... It's also a security risk if your web server is the only one doing it, as it is a way for an attacker to fingerprint the web server software in use. I understand and agree with melx's view here completely, even if I do feel Caddy's strengths outweigh it's weaknesses.
  - user3939382 3y ago
    > Who is looking devs presumably
    - mholt 3y ago
      Which is exactly the audience we were targeting. I thought it was a good idea at the time. ¯\_(ツ)_/¯
      - user3939382 3y ago
        I think it’s a cool idea, though if it’s on by default, disabling it should be obvious like one of the first lines in the config file.
- doublerabbit 3y ago
  It is bad taste, unprofessional. Taints the pool with the vibe of "We can do this; we will do this and you schmucks can't do anything about it because it's in the EULA". Regardless to how harmless it is. It's still an unprofessional quality to implement such and then deny the ability to disable it. Same example as if when you honked your cars horn it tooted the car model. You'd be annoyed right? Sure, its harmless because how often do you use your car horn but you expect a car horn to horn not advertise the model your driving.
  - Symbiote 3y ago
    I'm imagining a Tesla's horn chiming the Intel "dah dah ding ding" thing now. Let's hope Elon doesn't read this.
- melx 3y ago
  > Adding a sponsor header is harmless Harmless or not - I think it's worth looking past this point. Maybe the http header was a way for them to search the internet and find *commercial* sites that didn't pay for Caddy license? Not very pro behaviour.
  - sergiosgc 3y ago
    Caddy is licensed under the Apache license, which allows for commercial use. No one is infringing by not paying for the commercial version.
    - melx 3y ago
      Well, we're in 2017 (read the thread I posted above), and in that year Caddy was distributing[0] the binary as licensed product. Apache licence applied to its source-code only (e.g. when you build the server from source - which only few people did). [0] https://web.archive.org/web/20180216153020/https://caddyserver.com/products/licenses https://web.archive.org/web/20180216153020/https://caddyserv...
      - sergiosgc 3y ago
        Thanks for the background. I didn't know it used to be like that. It's a funky licensing scheme if I ever saw one.
intelVISA 3y ago
You can't expect a program in Go to compete with Rust or C++. When they say it's "fast" they mean relative to something like Python.
- dathinab 3y ago
  I don't think language comparisons make sense here as a ton of performance is application dependent. So when it says it's "fast" it should be "fast" compared to many but not necessary all alternative similar software ignoring any language (which it probably is, some of the alternatives are not fast even through they are written in C AFIK). Through in this case I would say it being "fast enough" for many use-cases is the relevant part.
- diarrhea 3y ago
  I was under the impression GCed languages aren’t necessarily slower than non-GC. Rust still cleans up after itself (RAII and destructors). The difference is in latency, predictability and perhaps total memory use; but not actual speed, I thought.
  - steveklabnik 3y ago
    The part you're missing is secondary effects of designing a language around GC. Most of the time, that means that everything is heap allocated. So even if a GC and RAII-style management did the same amount of work (and they generally don't, GC's often do less when allocating, for example) while doing allocation/deallocation, non-GC'd languages tend to allocate less in the first place. Additionally, if we're talking about overall performance, indirection can be quite bad on cache locality, so it's not even purely about the speed of allocation/deallocating, but about pointer chasing. Some GC'd languages also offer tools to manage these problems, of course, all I mean to say is that there are a lot of factors at play here.
h1fra 3y ago
I don't think they are really competing with nginx. They are just in the sweetspot between convenience vs performance.
ilyt 3y ago
I just keep using HAProxy for doing the plumbing and keeping app side as simple as possible (which is often just "a web server builtin into app" + maybe static serving nginx if app is in slow language that can't handle serving statics quickly) But automatic https does look convenient, no need to have separate certbot running
- melx 3y ago
  HAProxy 2.8 has improved[0] Let's Encrypt integration by using acme.sh (so you can get rid of certbot). It still needs a cron job/systemd timers to do renewal of certs but acme.sh is just bash script so you don't need (extra?) system deps for installing it, while certbot requires Python and 12 python libs on my system (Fedora). And nowadays the "recommended" way to get certbot is via Snap (package manager)... [0] https://www.haproxy.com/blog/haproxy-and-let-s-encrypt https://www.haproxy.com/blog/haproxy-and-let-s-encrypt
- anakaine 3y ago
  We use Caddy in production. The driving force for change was built in automatic https. It just simply works.
  - mholt 3y ago
    I'm happy to hear this -- we work hard on our auto-HTTPS features!
- eyegor 3y ago
  Haproxy is great in the end but it is pretty awful to work with. Once you've toiled in the mines of acl commands, going back to nginx/caddy is a breath of fresh air. Unless recent versions have completely changed the game, using haproxy when you don't have to is a massive time waster.
robertlagrant 3y ago
My problem is that Caddy does not ship an X-Clacks-Overhead header by default.
- Whitestrake 3y ago
  I tried to submit the Caddy configuration for this to www.gnuterrypratchett.com, but looking at it, it doesn't seem like it was ever added to the site. The configuration is simply: Header X-Clacks-Overhead "GNU Terry Pratchett"

by melx 3y ago

j-a-a-p 3y ago

> it's no longer present in current Caddy but the bad taste still remains Adding a sponsor header is harmless (albeit useless IMO). For me that would be no reason to not choosing this software, and certainly no ground for having a 'bad taste'.

rekoil 3y ago
What purpose does it actually fulfil? Who is actually looking at individual HTTP requests like this? All it does is take up extra traffic... It's also a security risk if your web server is the only one doing it, as it is a way for an attacker to fingerprint the web server software in use. I understand and agree with melx's view here completely, even if I do feel Caddy's strengths outweigh it's weaknesses.
- user3939382 3y ago
  > Who is looking devs presumably
  - mholt 3y ago
    Which is exactly the audience we were targeting. I thought it was a good idea at the time. ¯\_(ツ)_/¯
    - user3939382 3y ago
      I think it’s a cool idea, though if it’s on by default, disabling it should be obvious like one of the first lines in the config file.
doublerabbit 3y ago
It is bad taste, unprofessional. Taints the pool with the vibe of "We can do this; we will do this and you schmucks can't do anything about it because it's in the EULA". Regardless to how harmless it is. It's still an unprofessional quality to implement such and then deny the ability to disable it. Same example as if when you honked your cars horn it tooted the car model. You'd be annoyed right? Sure, its harmless because how often do you use your car horn but you expect a car horn to horn not advertise the model your driving.
- Symbiote 3y ago
  I'm imagining a Tesla's horn chiming the Intel "dah dah ding ding" thing now. Let's hope Elon doesn't read this.
melx 3y ago
> Adding a sponsor header is harmless Harmless or not - I think it's worth looking past this point. Maybe the http header was a way for them to search the internet and find *commercial* sites that didn't pay for Caddy license? Not very pro behaviour.
- sergiosgc 3y ago
  Caddy is licensed under the Apache license, which allows for commercial use. No one is infringing by not paying for the commercial version.
  - melx 3y ago
    Well, we're in 2017 (read the thread I posted above), and in that year Caddy was distributing[0] the binary as licensed product. Apache licence applied to its source-code only (e.g. when you build the server from source - which only few people did). [0] https://web.archive.org/web/20180216153020/https://caddyserver.com/products/licenses https://web.archive.org/web/20180216153020/https://caddyserv...
    - sergiosgc 3y ago
      Thanks for the background. I didn't know it used to be like that. It's a funky licensing scheme if I ever saw one.

intelVISA 3y ago

You can't expect a program in Go to compete with Rust or C++. When they say it's "fast" they mean relative to something like Python.

dathinab 3y ago
I don't think language comparisons make sense here as a ton of performance is application dependent. So when it says it's "fast" it should be "fast" compared to many but not necessary all alternative similar software ignoring any language (which it probably is, some of the alternatives are not fast even through they are written in C AFIK). Through in this case I would say it being "fast enough" for many use-cases is the relevant part.
diarrhea 3y ago
I was under the impression GCed languages aren’t necessarily slower than non-GC. Rust still cleans up after itself (RAII and destructors). The difference is in latency, predictability and perhaps total memory use; but not actual speed, I thought.
- steveklabnik 3y ago
  The part you're missing is secondary effects of designing a language around GC. Most of the time, that means that everything is heap allocated. So even if a GC and RAII-style management did the same amount of work (and they generally don't, GC's often do less when allocating, for example) while doing allocation/deallocation, non-GC'd languages tend to allocate less in the first place. Additionally, if we're talking about overall performance, indirection can be quite bad on cache locality, so it's not even purely about the speed of allocation/deallocating, but about pointer chasing. Some GC'd languages also offer tools to manage these problems, of course, all I mean to say is that there are a lot of factors at play here.

h1fra 3y ago

I don't think they are really competing with nginx. They are just in the sweetspot between convenience vs performance.

ilyt 3y ago

I just keep using HAProxy for doing the plumbing and keeping app side as simple as possible (which is often just "a web server builtin into app" + maybe static serving nginx if app is in slow language that can't handle serving statics quickly) But automatic https does look convenient, no need to have separate certbot running

melx 3y ago
HAProxy 2.8 has improved[0] Let's Encrypt integration by using acme.sh (so you can get rid of certbot). It still needs a cron job/systemd timers to do renewal of certs but acme.sh is just bash script so you don't need (extra?) system deps for installing it, while certbot requires Python and 12 python libs on my system (Fedora). And nowadays the "recommended" way to get certbot is via Snap (package manager)... [0] https://www.haproxy.com/blog/haproxy-and-let-s-encrypt https://www.haproxy.com/blog/haproxy-and-let-s-encrypt
anakaine 3y ago
We use Caddy in production. The driving force for change was built in automatic https. It just simply works.
- mholt 3y ago
  I'm happy to hear this -- we work hard on our auto-HTTPS features!
eyegor 3y ago
Haproxy is great in the end but it is pretty awful to work with. Once you've toiled in the mines of acl commands, going back to nginx/caddy is a breath of fresh air. Unless recent versions have completely changed the game, using haproxy when you don't have to is a massive time waster.

robertlagrant 3y ago

My problem is that Caddy does not ship an X-Clacks-Overhead header by default.

Whitestrake 3y ago
I tried to submit the Caddy configuration for this to www.gnuterrypratchett.com, but looking at it, it doesn't seem like it was ever added to the site. The configuration is simply: Header X-Clacks-Overhead "GNU Terry Pratchett"