确定是增加还是减少我正在运行的基于云的 Web 服务器的数量有什么好的经验法则？除了请求执行时间、处理器利用率、可用内存和每秒请求数之外，是否还有其他指标需要为此监控？是否应该使用加权平均值、标准偏差或其他一些计算来确定放大或缩小？最后，是否有任何特定值最适合确定何时添加或减少服务器实例？
【问题讨论】：
标签： performance webserver cloud
这个动态分配计算实例的问题让我想起了我在工程学校的控制系统课程。看来我们应该能够将经典的数字控制系统算法（想想 PID 循环和 Z 变换）应用于扩展服务器。启动服务器实例类似于将发动机油门的步进电机移动一个档位，以增加燃料和氧气的速率以响应增加的负载。响应太慢，性能迟缓（过阻尼），太快，系统变得不稳定（阻尼不足）。
在计算域和物理域中，目标是使资源匹配负载。好消息是计算系统是更容易处理的控制系统之一，因为拥有太多资源不会导致不稳定；它只是花钱，类似于在带有电阻器组的系统中发电来燃烧多余的电量。
很高兴看到基本面如何再次出现！我们学会了这一切是有原因的。
【讨论】：
您的问题是目前的热门研究领域。但是，云提供商可以以不同的方式自动化 Web 服务器的使用。有关详细信息，它是如何工作的？哪些指标会影响放大和缩小：你可以看看这个paper。
Amazon 宣布了 Elastic Beanstalk，它允许您将应用程序部署到 Amazon 的 EC2（弹性计算云）并根据需要通过启动或终止服务器实例来扩大或缩小应用程序。使用 Elastic Beanstalk 无需额外费用；您需要为您使用的实例付费。
此外，您还可以查看亚马逊 AWS 提供的 Auto Scaling。
Auto Scaling 允许您扩展您的 Amazon EC2 容量自动增加 或者根据你的条件下来 定义。使用 Auto Scaling，您可以 确保 Amazon EC2 的数量 您正在使用的实例增加 在需求高峰期间无缝地 保持性能并降低 在需求平缓期间自动 最小化成本。自动缩放是 特别适合 每小时体验的应用程序， 每天或每周的使用变化。 Auto Scaling 由 Amazon 启用 CloudWatch，不提供 亚马逊以外的额外费用 CloudWatch 费用。
我建议您阅读 Amazon AWS 的详细信息，以了解他们的系统如何利用 Web 服务器的纵向扩展和缩减。
【讨论】：