-
一个每次请求都 new 一个 HttpClient 再 Dispose 的写法,在高并发下把服务器端口耗尽、抛出无法分配地址的异常:一次 HttpClient 误用的深度复盘
对外调用第三方的服务,一到高峰就大面积抛 SocketException(无法分配请求的地址),第三方却说一切正常,自己 CPU 内存也不高。netstat 一看几万个 TIME_WAIT 把本地端口耗尽了。根因是每次调用都 new 一个 HttpClient、用完 using Dispose——这看似标准,可 HttpClient 内部维护连接池、被设计为长期复用,频繁 new+dispose …- 0
- 0
-
.NET HttpClient 单例 + K8s 滚动发布失联 4 小时复盘:SocketsHttpHandler 默认 PooledConnectionLifetime 灾难
.NET 8 计费网关上游服务做了次普通滚动发布,我们的 HttpClient 单例对着已经回收的旧 Pod IP 持续报错 18 分钟。SocketsHttpHandler 默认 PooledConnectionLifetime 是无限,DNS 永不刷新。完整复盘 + 6 步自查清单。- 0
- 0
-
C# async-over-sync 反模式 + HttpClient 端口耗尽两连击雪崩复盘:从 P99 11s 到 115ms 的全过程
一个 ASP.NET Core 服务在大促预热被两个 .NET 经典反模式同时打中:async-over-sync 的假异步引发 ThreadPool 饥饿,叠加 new HttpClient 引发端口耗尽,CPU 才 28% 但 P99 飙到 11 秒。本文复盘事故时间线、五种修法、性能基准对比、以及我们立下的 8 条 .NET 异步纪律,帮所有 .NET 团队避开同样的雪崩。- 0
- 0
-
TIME_WAIT 堆到四万:一次 HTTP 客户端连接池踩坑的复盘
一个对外调用频繁的聚合服务,调第三方 API 平时几十毫秒,高峰却飙到一两秒,机器上 TIME_WAIT 堆了四万多个、端口几乎耗尽。根子是 HTTP 客户端用得太随意:每次请求 new 一个 client,连接用完就扔。几天梳理 HTTP 客户端:连接池配置、连接泄漏、三个超时、连接保活、客户端监控。- 0
- 0
HttpClient
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×