4 ms·

About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache reta

About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine for most applications. There are other reasons to use nginx, and there are other reasons to use Apache. Both are fine, and I hear https://caddyserver.com/ https://caddyserver.com/ is coming in hot!

mholt 5y ago
Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.
- throw_m239339 5y ago
  > Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities. At the expense of the memory footprint because developed with Go. Hi Caddy creator!
  - eric_h 5y ago
    > At the expense of the memory footprint because developed with Go. Hi Caddy creator! Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
    - deleted 5y ago
      [deleted]
    - arp242 5y ago
      I don't use Caddy, but I've written plenty of Go apps (which usually implement their own HTTP server with net/http) with plenty of users, and memory usage has never been much of a concern. There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases. [1]: https://news.ycombinator.com/item?id=28608083 https://news.ycombinator.com/item?id=28608083
  - whateveracct 5y ago
    We're talking about shaving megs here rofl cmon now terminal systems engineer brain is everywhere
- SahAssar 5y ago
  Might be nice to disclose your involvement when commenting on caddy-related threads.
  - mholt 5y ago
    > I'm the author of the Caddy web server.
    - SahAssar 5y ago
      I'm guessing you mean the about section of your profile. I'm just saying that it's nice to make that more visible when you have that sort of involvement in the topic and it is not obvious.
      - 0des 5y ago
        Why? I prefer when people don't flash their badge at me to support their statements. Words should stand on their own without appeals to authority.
        SahAssar 5y ago
        It's more the other way around, when saying things about your own product it's nice to disclose your involvement since that definitely colors your view. Especially in cases like this where it's hyping the product.
- klaussilveira 5y ago
  Definitely not the right place, but thank you for creating Caddy. :)
  - mholt 5y ago
    Thanks, you're welcome!
killingtime74 5y ago
Caddy also does the whole Let’s Encrypt thing for you for SSL
- yourad_io 5y ago
  There's a plugin for nginx that works well: $ apt-get install python3-certbot-nginx $ sudo certbot --nginx -d example.com -d www.example.com https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/ https://www.nginx.com/blog/using-free-ssltls-certificates-fr... On the other hand, caddy seems to auto renew them as well - one less cron job: > Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed. https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https Neat, but still not sold.
  - yjftsjthsd-h 5y ago
    certbot works with apache, if you're willing to spend that effort
  - francislavoie 5y ago
    What are you not sold on?
  - arp242 5y ago
    I never cared much for certbot because "sudo certbot" and it works by rewriting config files. I don't really fancy running it as root (which can probably be avoided with some muckery, but still) or a program automatically rewriting my configs. Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.
jart 5y ago
redbean is a pure fork() web server and according to ab it is much faster than nginx. I feel like we've come full circle with history. Apache started off with fork() since it offers the strongest security versus other i/o models. The problem is that code bloat makes fork() go slower so as Apache ballooned over the years there was this race to the bottom in terms of i/o models, caused by tragedy of the commons. https://youtu.be/1ZTRb-2DZGs?t=761 https://youtu.be/1ZTRb-2DZGs?t=761
xorcist 5y ago
To be fair, the event worker in Apache and nginx are roughly the same age, 2004. Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time. What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them. And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
- trulyme 5y ago
  Nginx configs do look more readable, but they have a lot of gotchas themselves. Quite surprising actually.
- innocenat 5y ago
  I agree wholeheartedly that php-fpm rapidly speed up nginx adoption. Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.

mholt 5y ago

Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.

throw_m239339 5y ago
> Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities. At the expense of the memory footprint because developed with Go. Hi Caddy creator!
- eric_h 5y ago
  > At the expense of the memory footprint because developed with Go. Hi Caddy creator! Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
  - deleted 5y ago
    [deleted]
  - arp242 5y ago
    I don't use Caddy, but I've written plenty of Go apps (which usually implement their own HTTP server with net/http) with plenty of users, and memory usage has never been much of a concern. There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases. [1]: https://news.ycombinator.com/item?id=28608083 https://news.ycombinator.com/item?id=28608083
- whateveracct 5y ago
  We're talking about shaving megs here rofl cmon now terminal systems engineer brain is everywhere
SahAssar 5y ago
Might be nice to disclose your involvement when commenting on caddy-related threads.
- mholt 5y ago
  > I'm the author of the Caddy web server.
  - SahAssar 5y ago
    I'm guessing you mean the about section of your profile. I'm just saying that it's nice to make that more visible when you have that sort of involvement in the topic and it is not obvious.
    - 0des 5y ago
      Why? I prefer when people don't flash their badge at me to support their statements. Words should stand on their own without appeals to authority.
      - SahAssar 5y ago
        It's more the other way around, when saying things about your own product it's nice to disclose your involvement since that definitely colors your view. Especially in cases like this where it's hyping the product.
klaussilveira 5y ago
Definitely not the right place, but thank you for creating Caddy. :)
- mholt 5y ago
  Thanks, you're welcome!

killingtime74 5y ago

Caddy also does the whole Let’s Encrypt thing for you for SSL

yourad_io 5y ago
There's a plugin for nginx that works well: $ apt-get install python3-certbot-nginx $ sudo certbot --nginx -d example.com -d www.example.com https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/ https://www.nginx.com/blog/using-free-ssltls-certificates-fr... On the other hand, caddy seems to auto renew them as well - one less cron job: > Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed. https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https Neat, but still not sold.
- yjftsjthsd-h 5y ago
  certbot works with apache, if you're willing to spend that effort
- francislavoie 5y ago
  What are you not sold on?
- arp242 5y ago
  I never cared much for certbot because "sudo certbot" and it works by rewriting config files. I don't really fancy running it as root (which can probably be avoided with some muckery, but still) or a program automatically rewriting my configs. Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.

jart 5y ago

redbean is a pure fork() web server and according to ab it is much faster than nginx. I feel like we've come full circle with history. Apache started off with fork() since it offers the strongest security versus other i/o models. The problem is that code bloat makes fork() go slower so as Apache ballooned over the years there was this race to the bottom in terms of i/o models, caused by tragedy of the commons. https://youtu.be/1ZTRb-2DZGs?t=761 https://youtu.be/1ZTRb-2DZGs?t=761

xorcist 5y ago

To be fair, the event worker in Apache and nginx are roughly the same age, 2004. Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time. What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them. And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.

trulyme 5y ago
Nginx configs do look more readable, but they have a lot of gotchas themselves. Quite surprising actually.
innocenat 5y ago
I agree wholeheartedly that php-fpm rapidly speed up nginx adoption. Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.