【问题标题】：Why Azure ASP (App Service Plan) manual scale-up is too slow?为什么 Azure ASP（应用服务计划）手动扩展太慢？
【发布时间】：2021-01-16 19:09:40
【问题描述】：
目前，我有一个 Azure ASP I1，其中包含大约 8 个应用服务和 2 个功能应用。
当我从 1 个实例手动扩展到 2 个实例时。它花费大约30多分钟，我认为它太慢了。
我的问题：
- 影响刻度时间的原因有哪些？ （资源、应用的数量？）
- 如何减少手动缩放时间？ （我的意思是配置的最佳实践）
- 如果我们对此 ASP 应用自动缩放，它的缩放速度会更快吗？否则，自动缩放不会带来任何价值，因为当缩放完成的那一刻，我们服务器的压力可能已经减少了。
任何部分答案和讨论将不胜感激
【问题讨论】：
标签：
azure
web-services
cloud
scale
【解决方案1】：
我对扩展的理解是，它是配置服务计划下的所有资源所需时间的简单总和。你说，你有 8 个应用服务和 2 个功能应用。试着回想一下配置它们需要多长时间。如果每个应用程序花费大约一分钟，那么大约需要 10 分钟。例如，如果您的应用程序有一个 cosmos db，那么这将需要 3 到 10 分钟。我是根据我自己的经验说的。
那么，现在，回答您的问题。
- 影响刻度时间的原因有哪些？ （资源、应用的数量？）
是的，单个应用程序及其所依赖的资源是决定扩展时间的重要因素。
- 如何减少手动缩放时间？ （我的意思是配置的最佳实践）
不多。这是您无法控制的情况之一。
但是，如果我是你，我会考虑将一些应用程序和功能从该服务计划中移出，并可能单独管理它们？
假设我有一个带有数据库服务的网络应用程序。我发现服务器能够很好地处理负载，但数据库需要更大的计划。然后，我不会将它们保持在同一个计划中，而是将数据库移动到一个单独的计划中，只将扩展工作集中在数据库上，而将 Web 应用程序服务放在一边。
- 如果我们对此 ASP 应用自动缩放，它的缩放速度会更快吗？
没有。