IHTTPCLIENTFACTORY每次都会创建新的HTTPClient？
我正在使用ASP.NET Core 6开发Web API应用程序。
我看到IHTTPCLIENTFACTORY createClient方法每次都会创建HTTPCLIENT的新实例。
根据 this
每次我们要求httpclient时，我们都会得到一个新实例，可以 （或可能不会）使用现有的HTTPCLIENTHANDLER。 httpclient本身 它不是太重而无法构造，所以这还可以。
你分享这个观点吗？ httpclient真的这样可以引起性能问题吗？
如果实际上存在性能问题，那么处理它们的最佳方法是什么？
I am developing a Web Api application with Asp.Net Core 6.
I see that the IHttpClientFactory CreateClient method creates a new instance of HttpClient every time.
According to this article
Each time we ask for a HttpClient, we get a new instance, which may
(or may not) use an existing HttpClientHandler. The HttpClient itself
it not too heavy to construct so this is okay.
Do you share this view? Is HttpClient really that light that it doesn't cause performance problems?
If there are actually performance problems, what is the best way to handle them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个典型的Web API应用程序具有许多为每个请求构建的依赖性依赖项。您的
dbContext是其中另一种。它不是太重。分配和垃圾收集是针对创建短寿命对象的高度优化的，因此开发人员不必担心它。所有最重要的优化是最大程度地减少认知载荷。如果实际上存在性能问题，那么处理它们的最佳方法将取决于导致它们的原因，您将通过分析运行应用程序来学习。但是可能不会出现性能问题。如果有的话，他们可能不会在您期望的地方。即使对于经验丰富的开发人员来说，这也是如此。
您现在担心的性能是RAW CPU和一些内存I/O。我不确定为什么新开发人员对此进行注定。大多数应用程序的瓶颈是磁盘和网络I/O。
A typical web API app has a lot of scoped dependencies that are constructed for each request. Your
DbContextis another of these. It's not too heavy. Allocation and garbage collection are highly optimized for the creation of short-lived objects so that developers don't have to worry about it. The most important optimization of all is minimizing cognitive load.If there are actually performance problems, the best way to handle them will depend on what caused them, which you'll learn by profiling your running app. But there probably won't be performance problems. And if there are, they probably won't be where you expected. This is true even for experienced developers.
The kind of performance you're worrying about right now is raw CPU and a bit of memory I/O. I'm not sure why new developers fixate on this. The bottleneck for most applications is disk and network I/O.