横向扩展的应用服务似乎扩展性较差。将所有流量导向 CPU 使用率为 100% 的实例

横向扩展的应用服务似乎扩展性较差。将所有流量导向 CPU 使用率为 100% 的实例

我有一个应用服务计划,已扩展到两个实例。我设法获取了这两个实例的统计信息,其中一个实例的 CPU 使用率为 100%,另一个实例的 CPU 使用率为 5%。这是一个问题,因为似乎所有 HTTP 请求都被发送到 CPU 使用率为 100% 的实例,因此网页加载速度非常慢。

我已按照以下方式关闭了 ARR Affinity这一页

所有 API 和 HTTP 请求都发送到同一实例还有其他原因吗?我该怎么做才能在两个实例之间公平地平衡负载?

答案1

所有 API 和 HTTP 请求都被发送到同一个实例还有其他原因吗?

如果您有负载均衡器,使用会话持久性您可以让同一个客户端访问同一个虚拟机。

在免费和共享层级中,应用在共享 VM 实例上获得 CPU 分钟数,并且无法扩展。在其他层级中,应用按如下方式运行和扩展。

在应用服务中创建应用时,该应用会被放入应用服务计划中。应用运行时,它会在应用服务计划中配置的所有 VM 实例上运行。如果多个应用位于同一个应用服务计划中,则它们都共享相同的 VM 实例。如果某个应用有多个部署槽,则所有部署槽也会在相同的 VM 实例上运行。如果启用诊断日志、执行备份或运行 WebJobs,它们也会使用这些 VM 实例上的 CPU 周期和内存。

这样,应用服务计划就是应用服务应用的扩展单位。如果计划配置为运行五个 VM 实例,则计划中的所有应用都会在这五个实例上运行。如果计划配置为自动扩展,则计划中的所有应用都会根据自动扩展设置一起扩展。

我该怎么做才能公平地平衡两个实例之间的负载?

您可以使用自动缩放条件根据指标(例如每个实例 50% CPU)缩放 VM。有关扩展应用的信息,请参阅手动或自动扩展实例数量

答案2

所以当我从 P2v2 降级到 S3 时,问题就解决了。这两个价格完全相同,一个是高级版,另一个是标准版。

现在所有请求都得到了均衡,网站响应时间从 10-12 秒下降到 60 毫秒,这是一个好的网站应该有的水平。

仍然不确定为什么会发生这种情况

相关内容