So the thing is I limited the memory to 100MB (because how much memory could you need to serve 1MB, even if every go-routine stack is 2-5kb and the references a

So the thing is I limited the memory to 100MB (because how much memory could you need to serve 1MB, even if every go-routine stack is 2-5kb and the references are all to one piece of data?) This was an issue, but I found that even with giving it more memory things didn't get much better -- the performance was still much worse. Weirdly enough, net/http did well memory wise (and reasonable performance wise, for Go), but I went to fasthttp since that was what was at the top of benchmarks for go, but the simplest you-would-think-this-would-work code didn't produce the results I would have expected. [EDIT] > edit: looking at their bug tracker, it might also be something like https://github.com/valyala/fasthttp/issues/518 https://github.com/valyala/fasthttp/issues/518: the request is not considered responded to so the goroutines never terminate. I don't know the fasthttp API at all tho, just looked for "leak" on their bug tracker and that stood out So I actually got some help from a reader which was pretty awesome (https://gitlab.com/mrman/kcup-go/-/merge_requests/7 https://gitlab.com/mrman/kcup-go/-/merge_requests/7), the fasthttp code performed much better after that. I should also mention that I got some advice that didn't pan out -- in particular using fasthttp.ServeFile (https://gitlab.com/mrman/kcup-go/-/merge_requests/9 https://gitlab.com/mrman/kcup-go/-/merge_requests/9)