6

我有一个在亚马逊弹性豆茎上运行的网站，其流量模式如下：

  • 通常约 50 个并发用户。
  • 发布到 Facebook 页面时，约 2000 个并发用户 1/2 分钟。

亚马逊网络服务声称能够快速扩展以应对此类挑战，但 cloudwatch 的“大于 x 超过 1 分钟”设置对于这种流量模式似乎不够快？

通常在几秒钟内所有 ec2 实例崩溃，杀死所有 cloudwatch 指标，整个站点停机 4/6 分钟。到目前为止，我还没有找到适用于这个场景的配置。

这是一个较小的事件的图表，该事件也杀死了该站点： 在此处输入图像描述

4

2 回答 2

3

这些链接是否可以按预期发布？如果是这样，您可以使用按计划扩展或作为替代方案，您可以更改 Auto Scaling 组的 DESIRED-CAPACITY 值，甚至as-execute-policy在链接发布之前触发直接扩展。

您知道您可以在一个组中拥有多个扩展策略吗？因此，您可能有针对您的案例的特殊 Auto Scaling 策略，SCALE_OUT_HIGH例如一次增加 10 个实例。看看as-put-scaling-policy命令。

此外，您需要检查您的代码并找到瓶颈。

您使用什么 HTTPD？考虑切换到 Nginx，因为它比 Apache 更快且资源消耗更少的软件。尝试使用 Memcache ... 像 Redis 这样的 NoSQL 进行高度读写也是不错的选择。

于 2012-06-26T05:46:37.087 回答
1

AWS 的建议如下：

我们一直在努力使我们的系统更具响应性，但是根据您的用例似乎需要，以几秒钟的响应时间自动配置虚拟服务器是一项挑战。也许有一种解决方法可以更快地响应，或者在请求开始增加时更具弹性。

您是否观察过如果您使用更大的实例类型或在稳定状态下使用更多的实例，站点的性能是否更好？这可能是一种应对入站请求快速增长的方法。虽然我承认它可能不是最具成本效益的，但您可能会发现这是一个快速解决方案。

另一种方法可能是调整您的警报以使用可以更快反映（或预测）您的需求增长的阈值或指标。例如，如果您将警报设置为在超过 75 或 100 个用户后添加实例，您可能会看到更好的性能。您可能已经在这样做了。除此之外，您的用例可能还有另一个预测需求增长的指标，例如，您的 Facebook 页面上的帖子可能会先于请求的显着增加几秒钟甚至一分钟。使用 CloudWatch 自定义指标来监控该值，然后将警报设置为 Auto Scale 也可能是一种潜在的解决方案。

所以我认为最好的答案是以较低的流量运行更多实例，并使用自定义指标来预测来自外部来源的流量。例如，我将尝试监控 Facebook 和 Twitter 中带有网站链接的帖子并立即扩大规模。

于 2012-06-26T15:33:55.763 回答