-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#356 #695 #1924 Custom HttpMessageInvoker
pooling
#1824
#356 #695 #1924 Custom HttpMessageInvoker
pooling
#1824
Conversation
Guys, Let's return to this awesome PR after Nov'23 release.. 🆗 ❔ |
@raman-m @RaynaldM I'm writing the test cases at the minute. No worries guys! I realized we can still simplify the logic, since the Downstreamroute is an immutable, no need to use the timeout as key parameter, the object reference is good enough. We might have problems in the future if allowing dynamic configuration though (1: empty the pool, then 2: load the new configuration). |
By the way, why not use the Record type instead? |
It is a good idea |
4d56fa2
to
8a62fba
Compare
👍 |
…i/Ocelot into features/http_client_pool
…ody is not copied by the api gateway.
@raman-m so, I have added a memory usage acceptance test in ContentTests. I have tried it with the current develop, and we can see a memory increase of about the payload size. In this PR, it is kept within a range of +/- 10 Mb @raman-m but we should be careful and foresee some field tests when merged to develop, since the refactoring is quite aggressive.... |
HttpMessageInvoker
pooling
@ggnaegi Yes, it is. Merging was done by you a couple of hours ago. I'll just press the button, there will be no merge conflicts with develop branch too. |
@raman-m I mean, wait on feedbacks from @RaynaldM and others before moving to release and create the packages ;-) |
Ha, making packages... No! I see you are so hot to release 🤣 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent job, Gui! 🤩
Hey guys, just asking. When will this be released ? Would need that for my project 👍 |
Hello, we have validated the behavior on production environments. It's looking good. we will finalize the release process in the next few days. |
@IamMartinPeek Soon... It will be released, I hope, on Monday, Feb 12... |
Closes #356 #695 #1924
After some checks, it seems impossible to use
HttpClientFactory
in the solution.There are several reasons for this:
HttpMessageHandler
can potentially be unique for each route. In the case of a "Named"HttpClient
, it's possible to useConfigurePrimaryHttpMessageHandler
, but this method will only be invoked the first timeHttpClientFactory.CreateClient("Named")
is called. In our case, this would mean that we are configuring as many "Named" clients as there are routes. This is not quite what we are looking for.HttpMessageInvoker
is potentially less resource-intensive thanHttpClient
. Of course,HttpMessageInvoker
is not returned byHttpClientFactory
and worse, if we force the cast, then we could face major performance problems.See: HttpClient vs HttpMessageInvoker buffering issue microsoft/reverse-proxy#458
I conclude that we must implement our own pool mechanism...
Thus, I propose a first draft of a solution using solutions borrowed from StackExchange and Microsoft. It will obviously have to be tested in detail, but it serves as a basis for discussion.
Proposed Changes
HttpMessageInvoker
instead ofHttpClient
SocketsHttpHandler
, introducing a new parameterPooledConnectionLifetime
inHttpHandlerOptions
IMessageInvokerPool
, the pool of message invokers, inspired by StackExchange implementationHttpClientBuilder
,HttpClientWrapper
and others)I will provide Acceptance and Unit tests later. You should @raman-m, @RaynaldM have a look at this draft. Thanks
Table 1: Performance with current http client
Table 2: Performance with the custom message invoker pool