3 ms·

On the Caddy website (https://caddyserver.com/ https://caddyserver.com/) it says: > Caddy is both a flexible, efficient static file server and a powerful, scal

by Zababa 5y ago

On the Caddy website (https://caddyserver.com/ https://caddyserver.com/) it says: > Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy. > LIGHTWEIGHT For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput. > STATIC FILES By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast. > Caddy's HTTP server has a wide array of modern features, high performance, and is easy to deploy. Emphasis with the italics being mine. All of these seem to hint at performance comparaisons being done in specific domains agaisnt other web servers. For example: - efficient static file server: I would assume that "efficient" here is compared to other file servers, though that could mean also that it doesn't use much resources - For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput: That seem to imply that other servers with all these features are heavier and less efficient? Or that other servers just don't have those features? Relatively low memory footprint and high throughput? Relative to what? - It's so brilliantly simple and works fast: What does fast mean here? Fast relative to what? Apache? The standard Go static file server? Python SimpleHTTPServer? - high performance: High compared to what? My goal here isn't to be confrontational. My point is that if there are all those claims on the main page of Caddy, then you must at some point have measured performance, resource usage and things like that against other servers. I think what people are asking is to substantiate those claims with data. You're right that it's hard to generate data in a way that applies perfectly to everyone use case. But then on what do you base all these claims? Why is Caddy called "the ultimate server"? At least that's why I'm wondering.

mholt 5y ago
Not everything needs to be read as a comparison to other products. Adjectives have meaning without competition. They can be interpreted as ratios, for example requests / available memory, or load / latency. It's not always about putting down other products. Both can be fast. Both can be efficient. Both can be fast and light. Both can be "high" without one having to be low in order for it to be valid to call it "high" -- because it's not always about the other product. This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX. Caddy's just fast and efficient, I don't care to defend that claim as much as people care to attack it.
- Zababa 5y ago
  I mean, I get your point, but adjectives don't exist in a vacuum. If everything is fast, everything is slow too, and nothing is fast too, because everything is the same. When you use an adjective like "fast" or "slow", you're separating yourself from the whole, and you're putting the thing you're talking about in a category. Of course this is relative. You can be a fast marathon runner. You can be a fast human. Or a fast animal. Or a fast car, or plane. All of those have vastly different speed. But they still have meaning. Now, Caddy is a web server. You say that it's fast and efficient. I'm not putting that into question. But what do you base that on? What would it take for Caddy to be judged as "slow" or "inefficient" by you? Maybe you don't have a precise answer, and that's perfectly okay. But you must have a way to evalute what's slow and what's fast, even when not comparing to other product. At least that's how I (and I assume, the people asking you all these questions) think. > This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX. That's fair, and I can empathize. However, I think that's what will happen when the first thing people see on the website of Caddy is "THE ULTIMATE SERVER". Ultimate, for a good amount of people, is related to performance, so people are going to ask you about that. And when they don't get a clear answer, they're going to get frustrated. Again, I'm not trying to be confrontational here. But there seems to be a real lack of understanding in this conversation, and I'm trying to clarify what people mean when they ask about Caddy's performance.
- Xevi 5y ago
  Then what do they mean to you? I think people are just trying to understand. What is "fast" and "efficient" to you? Where do you draw the line? When it comes to tech in particular, things are pretty much always compared relative to each other, because there's very little other reference points. React is generally deemed as slow relative to Svelte. Rust is more efficient than Python at runtime. These claims mean very little in a vacuum, in fact I'd say that they are almost pointless. You can't base you business decisions on claims that haven't been backed up by data. And if you do, you might regret them later on.

by Zababa 5y ago

mholt 5y ago

Not everything needs to be read as a comparison to other products. Adjectives have meaning without competition. They can be interpreted as ratios, for example requests / available memory, or load / latency. It's not always about putting down other products. Both can be fast. Both can be efficient. Both can be fast and light. Both can be "high" without one having to be low in order for it to be valid to call it "high" -- because it's not always about the other product. This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX. Caddy's just fast and efficient, I don't care to defend that claim as much as people care to attack it.

Zababa 5y ago
I mean, I get your point, but adjectives don't exist in a vacuum. If everything is fast, everything is slow too, and nothing is fast too, because everything is the same. When you use an adjective like "fast" or "slow", you're separating yourself from the whole, and you're putting the thing you're talking about in a category. Of course this is relative. You can be a fast marathon runner. You can be a fast human. Or a fast animal. Or a fast car, or plane. All of those have vastly different speed. But they still have meaning. Now, Caddy is a web server. You say that it's fast and efficient. I'm not putting that into question. But what do you base that on? What would it take for Caddy to be judged as "slow" or "inefficient" by you? Maybe you don't have a precise answer, and that's perfectly okay. But you must have a way to evalute what's slow and what's fast, even when not comparing to other product. At least that's how I (and I assume, the people asking you all these questions) think. > This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX. That's fair, and I can empathize. However, I think that's what will happen when the first thing people see on the website of Caddy is "THE ULTIMATE SERVER". Ultimate, for a good amount of people, is related to performance, so people are going to ask you about that. And when they don't get a clear answer, they're going to get frustrated. Again, I'm not trying to be confrontational here. But there seems to be a real lack of understanding in this conversation, and I'm trying to clarify what people mean when they ask about Caddy's performance.
Xevi 5y ago
Then what do they mean to you? I think people are just trying to understand. What is "fast" and "efficient" to you? Where do you draw the line? When it comes to tech in particular, things are pretty much always compared relative to each other, because there's very little other reference points. React is generally deemed as slow relative to Svelte. Rust is more efficient than Python at runtime. These claims mean very little in a vacuum, in fact I'd say that they are almost pointless. You can't base you business decisions on claims that haven't been backed up by data. And if you do, you might regret them later on.