The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.
And for what? My back end on a single host isn't pumping at 35k qps. If each request is 500 bytes, 35k qps is nearly 20mbps sustained with zero other io (in each direction). And this is using only two threads!
I think you'd be hard pressed to find an application where this is meaningfully useful versus just scaling horizontally. On a box that can run many threads in parallel, Caddy still vastly exceeds my ability to respond to pretty much any useful traffic. It's optimizing for a metric that wasn't a bottleneck in the first place.
> The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.
Does Spring Boot terrify you, then? Or Lua scripts in nginx? Or PHP? All of these use JIT compilation to run code that handles web requests.
Attack surface is a property of the JIT implementation, not of JIT itself. And eBPF is specifically designed to be very simple to implement and audit.
There's a big difference between a JIT like luajit which has lots of attention and fuzzing and one that's used by essentially nobody.
Would you compile your daily driver kernel with someone else's hobby C compiler that essentially nobody else uses?
> Does Spring Boot terrify you, then?
It should.
Why does jit compilation here scare you? eBPF has had a ton of research on how to limit its resource usage and how to sandbox it.
Except CDNs, where it is.
CDNs aren't running Caddy