I completely agree. Caddy looks promising, but being built with Go is advantage only in the sense of "I know Go so I can hack on Caddy". Otherwise it's actually a disadvantage. It's certainly slower.
Rather than reducing the discussion to "is C faster than Go", it's worth looking at benchmarks of any server you're looking at using. I thought the Caddy benchmarks looked quite good, maybe not as fast as Nginx or Lighttpd. So the question would be, is that extra level of performance so important to you that it outweighs the ease of use benefits, built-in Let's Encrypt support, etc? If yes then of course stick with the one that suits your needs.
However, all of those servers are so ridiculously fast that it's very unlikely that they would be the main bottleneck your site or web service faces.
The discussion started from answer on "Caddy ... built on newer technologies". I just pointed out that "newer technologies" does not necessarily mean "better".
That's a fair point. Actually I'm seeing a lot of cases recently where we seem to have forgotten about technical advances made in the past, and end up using systems today that are less robust in some ways.
I'm a full stack software engineer, linux system administrator, tech support specialist, and LGBT+ rights activist. I love old technology and collect old computers. Come say hi!
I see, that's interesting. Though I do like how easy caddy was to setup, so I guess that's an upside in some cases, at least for smaller sites that don't need the best performance on the net.
I really don't understand why some people consider application performance irrelevant. Better performance in same conditions means that less energy is wasted. In other words, better performing app is more environment friendly. Those who don't care about environment or believe that impact is too small to worry, may remember themselves that better performing app reduces bill for cloud hosting.
If everything is just about performance write your whole stack from scratch in assembly. See how that goes ;) The authors point is some sites will come up plenty fast enough on Caddy. Use what's best for your scenario. I don't use it myself but it seems like a good option.
@devimposter1
Sure, if you are just using it for your personal site, the performance difference shown in the benchmarks, doesn't matter at all. If you are running a relatively popular web-shop, it matters a lot.
"Amazon’s calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day–meaning they’d serve up many millions fewer online adverts."
fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales
Uh, it was supposed to be a joke about worrying about every single performance optimization for a web site that may have very little need. People still use Wordpress and other "fat" CMS's etc. without a problem...
Well, we're draining planet resources without a problem as well. And affecting climate without a problem too. Does that mean that we should not worry about these issues at all, if they don't cause any problems to us?
You're totally right that we should consider the efficiency (and therefore energy + cost) aspect. But it can't be the only thing we consider. If two options are equal in all respects except efficiency, there can be no question that we would choose the less efficient option.
However, if for example configuration is simpler, and managing SSL certs is very important, then it might make sense for someone to choose a less efficient option that has those other advantages. I'm sure you've run into configuration problems that wasted hours of your time -- that could be enough to cancel out the cost savings of the more efficient option.
Funnily enough Caddy handles medium load more efficiently than NGINX, with much lower times to first byte on average, and with much less CPU consumption. Matt (the project author) made the same findings and dropped them in a thread on the Caddy forums.
Performance is not the only factor to take into account though when building good software, and whilst C or the likes will outperform many languages when counting the Fibonacci sequence, it can't compete with the Go ecosystem when it comes to networking tools. Hell, Netflix uses Go for a huge part of its networking stack, and they boast one of the largest, most complex setups to date.
I'm all for questioning new or "hype" projects, but it's unfair to describe Caddy as such. NGINX is very dated, and whilst it performs fantastically in specific use cases, it's good to have a new alternative that's more forgiving in the many new challenges we face today.
Well, taking into account that vast majority of networking code across all operating systems is written in C or C++, Go ecosystem is more or less usable at best. And I know what I'm talking about because at one of my previous jobs I was writing networking tools in Go.
@sergiy
Yevtushenko
I came across your comment recently, on the other hand, comparing static HTML/dynamic content seem it's a good replacement for PHP-FPM+Nginx with just Go that gave more than 3x performance on a VPS with 1vCPU. At least, that the next logical step to consider since you are probably aware majority of websites on shared hosting are running PHP. Overpaying for lower performance efficiency is bad.
I completely agree. Caddy looks promising, but being built with Go is advantage only in the sense of "I know Go so I can hack on Caddy". Otherwise it's actually a disadvantage. It's certainly slower.
Rather than reducing the discussion to "is C faster than Go", it's worth looking at benchmarks of any server you're looking at using. I thought the Caddy benchmarks looked quite good, maybe not as fast as Nginx or Lighttpd. So the question would be, is that extra level of performance so important to you that it outweighs the ease of use benefits, built-in Let's Encrypt support, etc? If yes then of course stick with the one that suits your needs.
However, all of those servers are so ridiculously fast that it's very unlikely that they would be the main bottleneck your site or web service faces.
The discussion started from answer on "Caddy ... built on newer technologies". I just pointed out that "newer technologies" does not necessarily mean "better".
That's a fair point. Actually I'm seeing a lot of cases recently where we seem to have forgotten about technical advances made in the past, and end up using systems today that are less robust in some ways.
Just for reference caddy vs nginx benchmarks:
github.com/centminmod/centminmod-caddy-v2#http2-https-benchmarks
I see, that's interesting. Though I do like how easy caddy was to setup, so I guess that's an upside in some cases, at least for smaller sites that don't need the best performance on the net.
I really don't understand why some people consider application performance irrelevant. Better performance in same conditions means that less energy is wasted. In other words, better performing app is more environment friendly. Those who don't care about environment or believe that impact is too small to worry, may remember themselves that better performing app reduces bill for cloud hosting.
If everything is just about performance write your whole stack from scratch in assembly. See how that goes ;) The authors point is some sites will come up plenty fast enough on Caddy. Use what's best for your scenario. I don't use it myself but it seems like a good option.
For last 15-20 years it's very hard (if at all possible) for human to beat compiler optimization in real life tasks. So, your advice has little sense.
@devimposter1
Sure, if you are just using it for your personal site, the performance difference shown in the benchmarks, doesn't matter at all. If you are running a relatively popular web-shop, it matters a lot.
"Amazon’s calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day–meaning they’d serve up many millions fewer online adverts."
fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales
Uh, it was supposed to be a joke about worrying about every single performance optimization for a web site that may have very little need. People still use Wordpress and other "fat" CMS's etc. without a problem...
Well, we're draining planet resources without a problem as well. And affecting climate without a problem too. Does that mean that we should not worry about these issues at all, if they don't cause any problems to us?
You're totally right that we should consider the efficiency (and therefore energy + cost) aspect. But it can't be the only thing we consider. If two options are equal in all respects except efficiency, there can be no question that we would choose the less efficient option.
However, if for example configuration is simpler, and managing SSL certs is very important, then it might make sense for someone to choose a less efficient option that has those other advantages. I'm sure you've run into configuration problems that wasted hours of your time -- that could be enough to cancel out the cost savings of the more efficient option.
Completely agree. I just answered on an attempt to downplay importance of efficiency.
Funnily enough Caddy handles medium load more efficiently than NGINX, with much lower times to first byte on average, and with much less CPU consumption. Matt (the project author) made the same findings and dropped them in a thread on the Caddy forums.
Performance is not the only factor to take into account though when building good software, and whilst C or the likes will outperform many languages when counting the Fibonacci sequence, it can't compete with the Go ecosystem when it comes to networking tools. Hell, Netflix uses Go for a huge part of its networking stack, and they boast one of the largest, most complex setups to date.
I'm all for questioning new or "hype" projects, but it's unfair to describe Caddy as such. NGINX is very dated, and whilst it performs fantastically in specific use cases, it's good to have a new alternative that's more forgiving in the many new challenges we face today.
Well, taking into account that vast majority of networking code across all operating systems is written in C or C++, Go ecosystem is more or less usable at best. And I know what I'm talking about because at one of my previous jobs I was writing networking tools in Go.
@sergiy Yevtushenko
I came across your comment recently, on the other hand, comparing static HTML/dynamic content seem it's a good replacement for PHP-FPM+Nginx with just Go that gave more than 3x performance on a VPS with 1vCPU. At least, that the next logical step to consider since you are probably aware majority of websites on shared hosting are running PHP. Overpaying for lower performance efficiency is bad.
Oh, I certainly meant benchmarks and experience of people that tried it.