☰

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

tag-icon • tag-icon azure load-balancing azure-app-services
横向扩展的应用服务似乎扩展性较差。将所有流量导向 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 毫秒，这是一个好的网站应该有的水平。

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

相关内容