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