我正在对我们的系统进行压力testing。 目前，我们在东部地区有5个大型的ELB背后的实例。 在西部地区，我用3个小实例（用JMeter）来锤击系统。
在做一个testing时，只会将应用程序实例推到CPU限制的80％-90％（当时的阻塞点），我看到一个奇怪的行为，ELB报告说所有5个实例都“停止服务 – 瞬间错误 – 请稍后再检查“，所有的实例停止获取请求，约5-10秒后，一切恢复正常。 这种情况每30秒发生一次。 但！ 每次我运行testing都不会发生这种情况。 我只是跑了半小时的压力testing，相同的设置和一切工作完美。 到底是怎么回事？
顺便说一句，我的健康检查是
Ping Target: HTTP:80/index.html Timeout: 60 seconds Interval: 300 seconds Unhealthy Threshold: 10 Healthy Threshold: 2
所以这是没有办法的。 直到昨天，我从来没有碰到过这个。
我们也有一个短暂的“盒子无法正常运行的健康检查”问题，并且与亚马逊的支持一起，ELB和Apache KeepaliveTimeout之间存在交互。 如果运行状况检查间隔大于超时，则healch检查程序可以尝试重新使用错误的连接，并且testing失败并将您的实例从ELB中排除。 他们称我们的60秒间隔“非常长”。 我们现在正在搞乱它，但是尝试设置较低的时间间隔，并将其与Apache中的Keepalive设置相匹配。
对ELB进行压力testing的最好方法是获得他们提供的cname后面的ips。 用它们击中负载平衡器。 确保每个您select的ELB中至less有一个图像。 亚马逊dynamic扩展ELB后面的IPS，你的负载平衡器可能只是一个单一的IP。 我不确定你正在经历的零星的行为。
这可能是由于JVM或操作系统级别的DNScaching，所以您的所有请求都是敲击1 ELB IP，或者是分发，所以ELB本身成为故障点，而不是提供故障转移。
从JMeter 2.12及以上版本开始， DNS Cache Managerconfiguration元素可用于testing负载平衡应用程序。
请参阅DNScachingpipe理器：testing负载平衡应用程序的正确方法指南获取更详细的解释和说明。