Caddy Performance vs Nginx, Apache

Hi Caddy Community!

I’ve been looking into using Caddy, and some of the features look really nice. My only question is about the performance of Caddy compared to server software like Apache and Nginx.

I’m running several DigitalOcean droplets for different projects, and since I’m a poor student, I have to keep costs down. Is it true that Caddy has higher memory overhead than Nginx? If so, how much?

The benchmarks I’ve seen while searching the web have been really varied, and I would love some reliable sources so I can decide whether to make the switch.

Thank you!

Why not run your own performance tests? That’s the only way to know for sure. (But you have to know what you’re doing.)

Unfortunately, I don’t know what I’m doing :slightly_frowning_face:

My knowledge of servers comes solely from having run some based off of tutorials

Is there any software I could use to benchmark?

I’m running several DigitalOcean droplets for different projects, and since I’m a poor student, I have to keep costs down.

FWIW, all of Caddy’s infrastructure runs on low-powered DigitalOcean droplets.

Unless you’re operating at massive scale like a major CDN (even personal/private CDNs won’t have a problem) or something like that, Caddy will probably run just fine for you on commodity / virtualized hardware.

Performance testing is complex and nuanced, and whole books are written on the subject. And web servers especially are difficult because there are so many layers, abstractions, protocols, and hidden variables that you don’t find in cases where performance testing is really crucial like crypto optimizations in processor instructions, etc.

Frankly, I advise against sinking time into any sort of benchmarking unless you know what you’re doing and have very specific requirements and goals. Even then, avoid drawing conclusions from any singular benchmark testing until proper, thorough profiling is completed.

I almost never see web server performance testing done properly – pages of tables and percentages don’t compensate for lack of full understanding of the stack and a complete consideration for hidden variables, even though the results may look impressive and thorough. I always end my reading of performance tests of any kind of web server with, “What about this or that?” I never really find them satisfying.

What is satisfying, though, is setting up the software I’m trialing, configuring it, and starting to use it – in a test or staging environment if needed – and then if something is running too slowly, I do some true profiling and find out where the bottleneck is and see how to fix it.

I did it this week, in fact, testing Caddy 2’s new brotli encoder (spoiler: it’s really slow). Through proper debugging and profiling, it became very clear that encoding responses using brotli in real-time on a single-core machine with this particular pure-Go library (that was directly converted from C, so is very inefficient as a Go program, but is at least pure Go) is not going to work for my case.

And then the key is to avoid extrapolating beyond that, or trying to avoid applying that result to someone else and drawing a conclusion like, “Therefore, we see that _ is slower than _” because too much gets lost out of context. The author of that brotli library is quite happy with its performance apparently, since he is using it in his own projects. (And of course, brotli’s compression algorithm is slow/complex in theory too—which is another point to consider sometimes—but I wanted to hook it up anyway and see what happens.) From my test, I can’t tell you that brotli is slow and you shouldn’t use it. I can’t make recommendations, because the number of variables is too large.

Anyway, Caddy is fast enough for most (read: really really most, like, probably 99%+ of) users, and especially as a student, I suspect almost any web server would be fast enough for your needs. No DigitalOcean droplet is that constrained on memory unless you’re operating some in-memory cache, running a busy database, or doing some other heavy lifting on each request. In which case: you don’t have a web server problem, you have an architecture/design/configuration problem.

So to answer your question:

There aren’t any reliable sources.

Try it out! I dare you to switch. :slight_smile:


Alright, I’ll give it a try :+1:

1 Like

I’m delighted you are using Caddy but if you are a poor student checkout which offers unlimited domains for a single fee of $5.95 a month. I’ve been using them for 10 years and they are fabulous.

benchmarking is fun though - I did benchmark 13x VPS for DigitalOcean vs Upcloud vs Linode vs Vultr vs Hetzner unfortunately DO isn’t anywhere in the lead.

I haven’t gotten around to benchmark testing Caddy 1.x yet but old Caddy 0.1x benchmarks I did do at the time but it’s best to do your own comparison benchmarks for your own specific work loads and see. Will be interesting to see how Caddy 1.x performance scales as you add more HTTP headers to the requests (as in the past Caddy 0.1.x performance degradated as you added more HTTP headers.)

I personally use nghttp2’s h2load HTTP/2 HTTPS load tester for HTTP/2 HTTPS load tests h2load - HTTP/2 benchmarking tool - HOW-TO — nghttp2 1.47.0-DEV documentation

and for non-HTTPS I use my own forked version of wrk, wrk-cmm at GitHub - centminmod/wrk at centminmod

depending on your linux distribution nghttp2 and h2load might not be available or outdated so I build my own docker images for nghttp2 and h2load too


I’ll check it out, although DigitalOcean is just $5 a month

I’m glad you think it’s fun. :stuck_out_tongue: And we didn’t choose DO because we were trying to optimize performance… we’re not exactly a big-scale operation. Our build server runs on a droplet with a single CPU currently, so…

It’s probably about the same; we haven’t really worked on performance in Caddy 1. Would you like to help improve Caddy 2’s performance, however? Do you know how to profile Go programs?

Yeah though benchmarking can reveal picking the right underlying cpu for DO droplets can easily improve your performance even for the same price droplet plan = better performance for same price :smiley:

No GO programmer/coder, but if there’s guides/write ups of what to do, would be helpful :slight_smile:

I would love some help from the community to improve performance through profiling and careful optimizing! Here’s how to profile Go programs: Profiling Go Programs - The Go Programming Language

And here’s some documentation of the pprof package: pprof package - runtime/pprof -

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.