ASP.NET Core中如何正确使用MaxConnectionsPerServer及确定合理值？

1. 当前配置方式是否正确？是否应该取消该配置？ #

你当前通过HttpClientFactory的ConfigurePrimaryHttpMessageHandler设置MaxConnectionsPerServer的方式是完全正确的，符合ASP.NET Core的HttpClient配置最佳实践。

高负载时段出现的TaskCanceledException（目标服务响应正常的前提下），确实大概率是因为MaxConnectionsPerServer=10的限制导致请求排队超时——你的服务在高负载下发起的请求数超过了允许的并发连接数，后续请求只能排队等待空闲连接，而你的HttpClient超时设置为3秒，排队的请求还没等到连接就触发了超时。

不建议直接取消该配置：.NET Core 3.1-6.0中MaxConnectionsPerServer的默认值是64，虽然比10高，但如果你的服务高负载并发请求量超过64，还是会出现同样的问题；而且直接取消配置相当于放弃了对连接数的主动管控，可能导致目标服务被过多并发请求压垮。

2. 如何确定MaxConnectionsPerServer的合理值？ #

可以通过以下步骤逐步确定：

• 分析目标服务的承载能力：先获取目标服务OtherService的并发处理上限（比如通过其监控数据的CPU使用率、请求队列长度、最大并发连接数配置），你的客户端连接数不要超过这个上限，避免过度压测目标服务。
• 统计自身服务的并发请求需求：收集高负载时段，你的服务每秒需要向OtherService发起的并发请求数（可以通过自身服务的监控指标，如QPS、当前活跃请求数等计算）。
• 结合响应时间计算理论值：假设目标服务的平均响应时间是T（比如100ms），你的HttpClient超时是3秒，那么单个连接在超时时间内可以处理的请求数约为3000ms / T。所需的连接数=并发请求数 / 单个连接处理能力。例如：并发请求数是200，单个连接每秒处理10个请求（响应时间100ms），那么理论连接数至少需要20。
• 压测验证调优：从理论值开始，逐步调高MaxConnectionsPerServer的值（比如从20、40、64开始测试），进行高负载压测，观察TaskCanceledException是否消失，同时监控目标服务的负载情况，找到既能解决自身超时问题，又不会让目标服务过载的平衡点。
• 考虑连接复用特性：HTTP/1.1默认开启Keep-Alive，HttpClient会复用连接处理多个请求，所以不需要将连接数设置得和并发请求数完全一致，合理利用连接复用可以降低连接数需求。
• 多服务隔离配置：因为你部署了多个服务，每个服务的HttpClient应该独立配置MaxConnectionsPerServer，避免某一个服务的高负载耗尽所有连接资源，影响其他服务。

另外可以通过日志排查确认问题：在请求发起和完成时记录时间戳，计算请求等待连接的时间，如果等待时间接近3秒，就可以确认是连接数限制导致的超时。

内容的提问来源于stack exchange，提问作者Sergey Rubtsov