【问题标题】:How to choose between Azure App Service Plans on a slow performing App?如何在性能缓慢的应用程序上选择 Azure 应用程序服务计划?
【发布时间】:2020-10-03 19:51:32
【问题描述】:

各位程序员,

我知道这个问题不完全是关于编程的,如果 SO 不适合它,请随时关闭这个问题并指出我正确的论坛。

我开发了一个 .NET Core 3.1 应用,部署在 Azure 应用服务上,但我遇到了性能问题。

该服务由各种文件的 OCR 分析组成,OCR 部分由嵌入到 DLL 中的外部库执行。在我的笔记本电脑上,在本地运行服务时,OCR 部分(一行代码,没有 I/O,没有执行其他操作)需要一到两秒。不过,它占用了大量可用的 CPU。

对于正在处理的完全相同的文件,并监视完全相同的代码行,在 Azure 上在线运行时计算需要 6 到 8 秒,没有其他请求正在处理。该应用程序部署在 Azure Web 应用程序上,S1 生产计划(100 个ACU,大约 60 美元/月)。随着用户数量的增加,整体响应时间也在增加,这会影响整个系统的性能。

在我开始切换计划并花费客户的钱之前,我想确保我不会错过有关如何选择 Web 应用计划的重要内容。

  1. 首先,在所有其他条件相同的情况下,我是否应该期望 S1 生产 WebApp 在基于 CPU 的作业上比我自己的计算机?我的笔记本电脑配备了多核 i7-7700 CPU。这可能取决于许多外部参数,但如果有的话,我想听听一般的经验法则。
  2. 查看 Web 应用程序的最大 CPU 使用率时,峰值为 50-60%,参见下面的屏幕截图。这是否意味着 CPU 使用率不是此进程的瓶颈,因此我缺少其他内容?
  3. 对于如何为给定作业确定 Web 应用程序/服务器的维度,您会推荐哪些阅读材料?

感谢您的帮助,

【问题讨论】:

    标签: azure performance asp.net-core


    【解决方案1】:

    根据此文档https://azure.microsoft.com/en-us/pricing/details/app-service/linux/,S1 计划有 1 个 CPU 内核和 1.75 GB RAM,我想这就是为什么在云上花费更多时间的原因,即使指标显示 CPU 只看到 50 /60%。

    为了获得更好的性能,Microsoft 建议使用 PremiumV2 计划(现在也可以使用 Premium V3),但在您的情况下,我建议您将计划扩展到 S2 并配置应用程序,然后扩展到 S3 等等上...

    【讨论】:

    • Microsoft 一直在努力推动人们向更高层级迁移,即使这是不必要的。只是他们在追加销售。
    • 高级计划优于标准计划听起来合乎逻辑 :-) 但您的方法正是我想避免的:在不了解瓶颈的情况下增加计划。 “我想这就是为什么在云上花费更多时间的原因,即使指标显示 CPU 只看到 50/60%”,基于什么?您能否指出我的资源,解释为什么您的猜测不是凭空而来的?
    • @XavierAM 我同意你的观点,你可以分析你的应用程序并了解瓶颈在哪里,这是节省成本和优化的正确方法,也基于你的要求。但似乎您的 3 个问题是关于: - 应用程序服务计划层选择和期望与您当地的笔记本电脑 - CPU 瓶颈 - 推荐的读数我试图涵盖第 1 点和第 3 点,对于第 2 点,您可以扩大一会儿看看了解使用另一层有多少好处会发生什么,这也应该有助于了解 CPU 是否是瓶颈
    • Cpu peek 可能只有 50%,但是您的代码(或您使用的第三部分代码)可以设计为利用更多的 cpu 内核,这可能是您的应用程序比它慢得多的原因你当地的笔记本电脑。我只是建议放大和分析,以便更好地了解 CPU 是否是真正的瓶颈,你扫描放大,分析然后缩小,为什么不呢?
    • 实际上,您的“经验法则”比任何复杂的方法都要好。我升级到 PremiumV2,响应时间减半!
    【解决方案2】:

    通常,您永远不希望网络请求花费 6-8 秒,您需要在理想情况下考虑不同的架构,而不是增强您的服务器。

    您最适合进行相对快速的重构可能是 azure 存储 blob 和执行处理的 blob 存储触发的 azure 函数的组合,您应该能够将代码移动到 azure 函数。然后,网站将只处理上传并立即返回,理想情况下带有某种客户端可以用来检查文档状态的 ID。如果您不希望客户端手动检查状态,也可以使用其他基于事件的机制。

    【讨论】:

    • 更好的是,通过这种方法,您只需为使用 Azure Function consumption plan 的内容付费。
    • @Matt,我完全同意你的看法。我也在朝着这个方向努力。但就目前而言,出于许多我无法企及的原因,客户希望在单个 Web 请求中完成处理。否则将意味着重构调用服务,这还不是一个选项。
    猜你喜欢
    • 2020-07-10
    • 2023-03-19
    • 2021-04-23
    • 2021-10-19
    • 1970-01-01
    • 2023-01-31
    • 1970-01-01
    • 2015-08-27
    • 1970-01-01
    相关资源
    最近更新 更多