CPU、RAM 和 I/O 密集型代码在 Azure Functions 上运行缓慢答案

【问题标题】：CPU, RAM and I/O intensive code runs slowly on Azure FunctionsCPU、RAM 和 I/O 密集型代码在 Azure Functions 上运行缓慢
【发布时间】：2017-09-26 14:46:42
【问题描述】：

我们有一些相当占用 CPU、RAM 和 I/O 的代码（它会创建大量临时文件、解压缩、调整大小和压缩图像）。我们正在尝试将其集成到“无服务器”Web 应用程序中，并且看到我们的代码仅在 Windows 上运行，目前我们正在 Azure Functions 上对其进行测试。

我们观察到，我们的代码在 Azure Functions 上的运行速度比在我的本地工作站（Core i7-4790、16GB RAM、SSD）上慢得多。例如，一个典型的工作负载为我们提供了以下时间：

Dev workstation:                                2.47 sec
Azure Functions, "App Service" plan (S3 size): 10.59 sec
Azure Functions, "Consumption" plan:           15.96 sec

我们还发现，在“消耗”计划中，时间差异很大 - 一项特定工作给我们的时间在 112 到 153 秒之间变化。 S3“应用服务”计划中的相同作业需要 117 到 119 秒，而在我的工作站上大约需要 31 秒。

P3 的时序与 S3 相似，这与我预期的差不多，因为 CPU 和 RAM 规格相同。

所以我真的有几个问题：

我们可以做些什么来分析我们在 Azure 上运行的应用程序，以确定瓶颈可能在哪里？
尝试在 Azure Functions 上运行如此繁重的工作负载，我们疯了吗？
对于如何让我们的代码在功能更强大的硬件上运行，而无需承担管理虚拟机场的所有复杂性，是否有人有任何建议？

【问题讨论】：

你在哪里写这些文件？请注意，在消费计划中，d:\home 下的文件系统是从 Azure 文件装载的，并且 I/O 延迟非常高。您可以尝试在D:\local 下的本地存储中写入，看看是否有区别。同样在消费计划中，功能应用程序被关联到 1 个核心。您应该在无服务器上横向扩展而不是向上
感谢您的提示！我检查过，看起来我们所有的临时文件都是在 D:\local 下创建的，所以应该没问题。我们的代码不是高度并行的，所以我不认为核心亲和力会成为问题，但我会尝试在单个核心上本地运行它，看看会发生什么。

标签： performance azure azure-functions

【解决方案1】：

您可以远程分析应用服务应用（包括函数应用），请参阅this link。我用过 Kudu，效果很好。
真的取决于你的目标。您引用的时间对于某些应用程序来说非常合适。
这对于 SO 来说似乎是一个过于宽泛的问题。

更类似于 FunctionApp 的方法是尝试将长时间运行的函数分解为更小的短期运行函数，从而分解并潜在地并行化处理。

【讨论】：

感谢您的链接 - 我会查看这篇文章并在有需要报告的时候更新。
关于消费计划要记住的一点是，它们是 1 个虚拟核心实例，而 S3 是 4 个虚拟核心，而 i7-4790 是 8 个虚拟核心。因此，我完全同意将长期运行的函数分解为小的短期运行函数的建议。如果您正在寻找一种简单的方法来做到这一点，Functionless 是一个开源项目，可以做到这一点。完全披露，我创作了这个项目，我对自我推销不感兴趣，只是提到它的价值，以防它对你有帮助。