Hello everyone, We're building an API Gateway in our company. Basically what this gateway does is that it processes request from external clients and when doing so, it communicates with our microservices. Some request can have as much as 5 microservices to communicate with in order to be processed.
Now, previously we're using code generated with swagger-codegen <https://github.com/swagger-api/swagger-codegen> in order to make http requests to our microservices, but after facing a problem by doing so, we've decided to compose our own code using net/http. Then another problem arise, after initial stress test it seemed that by using the code we've composed, the throughput (how many requests it can process per set of time) is way worse than when we previously used swagger-codegen. After short investigation, the differences between each implementation that we've found is: Swagger-codegen instantiate a new http.Client for each request, capable to be injected by only http.Transport, whereas our implementation only use single http.Client to be shared when communicating with every microservices. I'm curious on how this would become a huge difference. My understanding with Go so far is that the one who pools connection is the http.Transport, not the http.Client. Has anyone encountered similar behavior or have/currently build this kind of system? If so, what kind of approach do you guys take? Do you: - Share single http.Client across every request, but with some kind of tweaking - Instantiate a separate http.Client for each host/microservice - Instantiate a http.Client on every request - or others I haven't got a clue about If anyone asking, yes, we've set the max_idle_connections and max_idle_connections_per_host in the http.Transport, so it's not default. Any kind of insights will be appreciated, since we're still early in adopting Go, thank you very much. :) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
