5 ms·
i will add to not use the default http.Client/Server, poor performance, instead use fasthttp
by freecodyx 8y ago
i will add to not use the default http.Client/Server,
poor performance, instead use fasthttp
- ainar-g 8y agoIIRC, fasthttp only supports a subset of HTTP. This may or may not be a deal-breaker for some people.
- ErikDub 8y agoIt serves everything that is required for an ad-server.
- acln 8y agoI like my HTTP package to actually speak as good an approximation of HTTP as it can, so fasthttp wouldn't be my first option. Furthermore, the HTTP stack doesn't show up on most web servers' profiles. net/http is better understood by the community, interoperates with libraries better (e.g. golang.org/x/oauth2), and is better supported. Use net/http.
- ErikDub 8y agoThe main issue with net/http is that it generates a lot of garbage which is definitely going to show up in your profile if you're handling a lot of requests per second.
- sagichmal 8y agoAllocation pressure imposed by net/http has never been a top K source of profile CPU burn in any service I’ve ever written, and I’ve written plenty of high-performance, high-QPS services. fasthttp is rarely if ever a good idea.
- kasey_junk 8y agoThis is terrible advice for something serving broadly to consumers. Fasthttp is great if you can limit your interactions to a minor testable subset of calls but otherwise its not suitable.
- remoteorbust 8y agoFirst off, the author of fasthttp has made some great packages that I do use in production. However, last time I looked fasthttp was great if you don't care about http2 support or streaming bodies. Unfortunately I do.