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.
I totally agree with you and we all know that (I have a good background and experience from my work in docker and kubernetes), but what we are trying is not to solve real-world problem, we are trying to optimize and enhance using different ways / algorithms to build something better and surely we have a vision. Thanks for your feedback
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.