我们正在努力解决请求超时的问题。基本上，我们的服务（基于HTTP节点js）应该支持每秒数千次的高请求速率。该服务部署在AWS EKS上并能正常工作。我们遇到的问题是，当请求速率超过一定速率时，我的客户端开始出现多个超时。
为了调查这个问题并消除底层，我们在超时问题仍然发生的情况下最小化了组件的数量。
目前，我们有两个极其简单的设置，其中一个可以清楚地重现问题
1.三个HTTP客户端分别以1KRPS加载服务，而服务直接部署在EC2机器上。监视此设置，未观察到任何超时错误。
1.相同的三个HTTP客户端分别使用1K RPS加载服务（在本例中为服务
部署为Docker容器。在1K RPS之后，我们开始超时。
通过观察这两个设置，我发现Docker容器包含的TIME_WAIT连接数是原来的3倍。
- 码头集装箱：三万五千至四万五千
- EC2示例：最大值16K
我已经说过，我试图减少使用sysctl设置的TIME_WAIT，这里是我正在试验的Docker容器网络配置
docker run -p 8081:8081 -p 8084:8084 \
--sysctl net.core.somaxconn=50000 \
--sysctl net.ipv4.tcp_max_syn_backlog=30000 \
--sysctl net.ipv4.tcp_fin_timeout=10 \
--sysctl net.ipv4.tcp_tw_reuse=1 \
--sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait=5 \
....不幸的是，这并没有大大改善整体情况
实际上应用了新的sysctl值，我用sysctl -a验证了它。
我猜我们的问题在码头货柜网络调优的某个地方。请告诉我如何开始处理它的相关资源。
2条答案
按热度按时间jyztefdp1#
相同的三个HTTP客户机分别使用1 KRPS加载服务，在本例中，服务被部署为一个Docker容器。
它是在EKS集群内部，还是在不同EC2示例上的独立Docker主机上？
如果您还没有检查这个场景，请检查一下--仅仅在容器中运行应用程序就会导致超时，这似乎相当奇怪。
如果所有的超时都只在EKS中观察到，那么你可以检查集群中的IngressController-可能是资源问题。另一个选择是检查AWS负载均衡器，尽管每秒1 k请求似乎不太可能。
z2acfund2#
在Windows机器上，我们尝试使用powershell命令更改time_wait间隔，以将条目添加到Windows注册表：
然而，它不起作用。
直到我们在启动Docker容器的主机上设置了这个值（并重新启动），然后新的time_wait间隔开始在Docker容器中工作。