使用HttpClient结合NServiceBus时遭遇严重延迟问题

嘿，我刚好碰到过类似的问题，结合你说的场景——用NServiceBus做POC，触发事件后发REST API通知，功能正常但并发时性能拉胯，而且用的是.NET Framework 4.6.1的静态HttpClient，大概率是ServicePointManager的默认连接数限制在搞鬼！我来给你一步步拆解解决方案：

问题核心原因 #

在.NET Framework里，ServicePointManager默认对同一个域名只允许2个并发HTTP连接，这是老版本的遗留限制。如果你的所有通知请求都发往同一个API域名，并发上来后请求会排队等待可用连接，直接导致性能暴跌。虽然你用静态HttpClient是正确的（避免频繁创建销毁带来的socket资源耗尽），但没配合调整连接数的话，这个限制就会成为瓶颈。

具体解决步骤 #

1. 全局调整ServicePointManager连接数 #

在初始化静态HttpClient之前，先把全局默认连接数调高，数值根据你的并发需求来，比如设置成100（可以后续根据监控调整）：

internal static void Initialize() 
{
    // 提升全局默认的最大并发连接数
    ServicePointManager.DefaultConnectionLimit = 100;
    // 关闭Nagle算法，减少小数据包的延迟
    ServicePointManager.UseNagleAlgorithm = false;
    // 禁用Expect100Continue，减少HTTP握手的额外开销
    ServicePointManager.Expect100Continue = false;
    
    // 初始化静态HttpClient
    _httpClient = new HttpClient();
    // 按需设置超时时间，避免请求挂起太久
    _httpClient.Timeout = TimeSpan.FromSeconds(30);
}

2. 针对特定API域名单独配置 #

如果你的通知API是固定域名，还可以单独给这个域名设置更高的连接数，比全局设置更精准：

var apiBaseUri = new Uri("https://your-notification-api-domain.com");
var servicePoint = ServicePointManager.FindServicePoint(apiBaseUri);
// 比如给这个API单独开150个并发连接
servicePoint.ConnectionLimit = 150;

3. 匹配NServiceBus的并发处理能力 #

还要确保NServiceBus端点的消息处理并发数和你的HTTP并发能力匹配，不然端点消费消息太快，HTTP请求发不过去，会导致消息堆积。你可以在端点配置里调整：

var endpointConfig = new EndpointConfiguration("YourNotificationSenderEndpoint");
// 设置消息处理的并发数，建议比HTTP连接数略低，避免过载
endpointConfig.LimitMessageProcessingConcurrencyTo(50);
// 配置重试策略，避免单个请求失败影响整体
endpointConfig.Recoverability().Immediate(x => x.NumberOfRetries(2));

4. 额外优化建议 #

• 用性能计数器监控：查看.NET CLR Networking下的Connections Established、Connection Pool Hits等指标，确认连接池是否够用
• 尝试HTTP/2：.NET Framework 4.6.1支持HTTP/2，如果你的API服务器也支持，开启后多路复用能大幅提升并发性能
• 复用HttpContent：避免每次请求都新建StringContent或JsonContent，可以考虑池化或者复用序列化后的内容，减少内存开销

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