我负载testing负载平衡的不同选项，并从Nginx，haproxy和清漆得到的结果很差。 我在Rackspace有一个4GB的负载均衡器，击中4x1GB的应用服务器。
我打了一个名为“/慢”的url，在响应之前故意等待500毫秒。 如果我直接点击应用服务器，它可以处理每秒1600-1800的连接速度。
如果我点击Nginx负载平衡器，它只能处理大约2000个连接。 我希望更接近4×1600 = 6000.下面是我用来testing它的命令。 这是在40个256 MB的实例上并行运行的。 我故意将num_call设置为1，因为我想查看连接性能。 任何高于这个，我开始得到很多错误。
httperf --server 50.56.80.227 --port 1555 --uri /slow --rate 50 --num-call 1 --num-conn 100 --timeout 5 这是我的nginxconfiguration： https ： //gist.github.com/1299501
所以，这是奇怪的事情，不pipe我使用nginx，haproxy还是varnish，我都得到了大致相同的结果。 但是，我testing了Rackspace的新型云平衡器，并获得了更好的性能（在7000 / s时performance很好）。 既然nginx和其他的都运行在我设置的实例上，并且rackspace平衡器没有运行，我猜测这个系统有些问题。 我宁愿使用我控制的平衡器，所以我可以添加caching，gzip，ssl和其他东西。
我怎样才能找出瓶颈呢？ 有什么我应该调整系统来获得更好的性能？ 我需要超过4GB的RAM吗？ （在testing中拉姆的使用率不高）。 任何其他的随机想法？
更新：我把平衡器的尺寸调整到了8GB，性能performance更好，达到6000-7000，或者与机架式平衡器相比。 这没有任何意义，因为它之前没有用完RAM。
更新：下面是一个httperf输出的例子，当我重载平衡器（在8GB的版本上，比以前更高，但错误是类似的）： https ：//gist.github.com/1299628
我也在Rackspace Cloud，我有一个非常类似的问题。 我相信问题是这样的：
Rackspace云服务器常见问题
从你所描述的内容来看，你只是简单地将可怜的带宽空间带给了我们，几乎完全让Varnish / Nginx提供的所有惊人的性能提升。
为了确认，使用iftop open重新运行一些基准testing，并且完全注意到每个服务器大小的rackspace提供的数量。