我提前为这个问题的长度道歉，但我想澄清我已经尝试过的内容。
设置：
- 4 个 t1.micro EC2 实例（客户端）
- VPC 中的 1 个 c1.medium EC2 实例（服务器）（位于 Amazon Elastic Load Balancer (ELB) 后面）
- 1 个在 c1.medium 上运行的简单 node.js 服务器（侦听 http 端口 3000，返回简单的“hello”html 字符串）
- 4 个 node.js 服务器（每个 t1.micro 上 1 个）使用针对 c1.medium 的自定义基准测试套件进行分布式负载测试
*客户端和服务器正在运行 Ubuntu，并将其文件描述符限制提高到 102400。
运行案例：
4 个客户端尝试每秒建立 n 个连接（简单的 http get 请求），范围从 400 到 1000，直到发出 80,000 个请求。服务器有一个硬响应等待时间 y，在它响应“hello”之前测试了 500、1000、2000 和 3000 毫秒。
问题：
在任何超过 500 个连接/秒的情况下，会有几秒钟（最多 10 或 15 个）停止，此时服务器不再响应任何客户端，客户端处于空闲状态等待响应。这始终是 31449 个请求。客户端显示在此期间保持的适当数量的 ESTABLISHED 连接（使用 netstat）。同时，服务器显示大约 31550 个 TIME_WAIT 连接。几秒钟后，服务器报告的这个数字开始下降，最终它再次开始响应客户端。然后，在稍后的总请求计数（例如 62198）中会出现相同的问题（尽管这不一致）。该端口的文件描述符计数也降至 0。
尝试的解决方案：
增加临时端口范围。默认值为 32768-61000，或大约 30k。请注意，尽管来自 4 个不同的物理客户端，但流量通过 ELB 的本地 ip 路由，因此所有端口都分配给该 ip。实际上，所有 4 个客户端都被视为 1，而不是每个客户端都能够使用完整端口范围的通常预期结果。因此，所有 4 个端口都限制为 30k，而不是 30k x 4 个总端口。所以我用 net.ipv4.ip_local_port_range 将端口范围增加到 1024-65535，重新启动服务器并观察到以下情况：
- 使用新的端口范围。观察到使用低至 1000 和高达 65000 的端口。
- 连接仍然卡在 31449。
- 在 31550 左右卡住 10-15 秒后，观察到处于 TIME_WAIT 状态的端口总数高达 50000。
其他 tcp 配置也发生了变化，彼此独立并相互结合，例如 tc_fin_timeout、tcp_tw_recycle、tcp_tw_reuse 和其他几个配置，但没有任何明显的改进。tcp_tw_recycle 似乎帮助最大，但它使客户端上的状态结果打印出奇怪且顺序错误，并且仍然不能保证连接不会卡住。我也明白这是一个危险的启用选项。
问题：
我只是想拥有尽可能多的连接，以便放置在 c1.medium 上的真实服务器在进行基准测试时具有较高的基线。除了重新编译内核或使服务器不稳定之外，我还能做些什么来避免碰到这个 31449 连接墙？我觉得我应该能够远远高于 500/s，并且我认为仅增加端口范围就应该显示出一些改进，但我显然还缺少其他东西。
谢谢！