been writing Go since 2011, have written many http servers, have never really worried about net/http performance. the bottleneck is usually the storage layer.

been writing Go since 2011, have written many http servers, have never really worried about net/http performance. the bottleneck is usually the storage layer. let's say you have no storage, your bottleneck is probably serialization. let's say you don't have serialization problems (except for net/http, optimizing which you could argue is a deserialization problem), what is the problem-domain that's being tackled where you have cpu-bound http performance problems where you shouldn't just use udp instead? let's say you have no storage or serialization problems, you have a lot of http traffic. if the whole thing is stateless, you add nodes behind a load balancer and call it a day. ok, none of those things apply: you're dealing with a CPU-bound, stateful http server with all of its state in memory, and it's not fast enough. you are, presumably, at scale and have customers or users; if you weren't at scale, you probably wouldn't be facing this sort of performance problem. so you use something like fasthttp to help you ... scale one node to a very large size? um, I guess you could do that, but now you have a lot of traffic and you've scaled a single point of failure. I just don't get it. I don't get what actual real-world problem this solves that isn't imaginary.