我们正在使用ELB进行SSL终止。 我们的应用程序使用HTTP在ELB后面的EC2实例上运行。 我们正在监视应用程序的响应时间，并在通过ELB时性能受到很大影响： – 通过ELB时的平均响应时间：1+秒 – 当ELB被旁路时的平均响应时间：〜250ms。
看起来ELB增加了大约一秒钟，偶尔会增加4-5秒。 这是预期的吗？ ELB SSLterminal添加的典型开销是多less？
任何指针将不胜感激！
这可能是由于ELB是如何为你configuration的，这绝对不正常。 ELB节点根据负载改变大小和规模。 如果您的网站没有收到很多stream量，那么您的ELB可能会缩小到更小的节点。 您应该通过高级支持或AWS论坛联系AWS，让他们检查出来。
对于那些有相似问题的人来说，如何诊断他们的ELB，我写了一个名为elbping的工具，旨在使ELB的诊断变得容易一些。 我专门编写了这个工具，通过在HTTP（s）模式下触发一个HTTP 405（方法不允许）ELB来testing所有的ELB节点是否响应。
它是一个rubygem，所以如果你有rubygems，那么你可以通过简单的安装它：
$ gem install elbping 现在你可以运行：
$ elbping -c 4 https://elb-123456789.us-east-1.elb.amazonaws.com Response from 54.243.63.96: code=405 time=210 ms Response from 23.21.73.53: code=405 time=189 ms Response from 54.243.63.96: code=405 time=191 ms Response from 23.21.73.53: code=405 time=188 ms Response from 54.243.63.96: code=405 time=190 ms Response from 23.21.73.53: code=405 time=192 ms Response from 54.243.63.96: code=405 time=187 ms Response from 23.21.73.53: code=405 time=189 ms --- 54.243.63.96 statistics --- 4 requests, 4 responses, 0% loss min/avg/max = 187/163/210 ms --- 23.21.73.53 statistics --- 4 requests, 4 responses, 0% loss min/avg/max = 188/189/192 ms --- total statistics --- 4 requests, 4 responses, 0% loss min/avg/max = 188/189/192 ms
如果你看到code=405那么这意味着ELB和它的节点正在响应。 这些“ping”永远不会到你的后端，所以这些响应时间只是往返ELB的往返时间。
在SSL的情况下，这将帮助您辨别与ELBbuild立SSL连接所需的时间，以及ELB与您的后端进行通信需要多长时间。
HTH
刚刚遇到这个问题，倾倒了一些知识，以防其他人遇到这种情况。
现在，ELB可以启用访问日志 ，这会为您提供一系列关于请求的不同指标，以便您可以判断ELB是否有问题，或者您的后端实例是否有问题。 （请参阅request_processing_time和backend_processing_time）