2017-06-06 41 views
1

我们有一些相当CPU,RAM和I/O密集型代码(它会创建大量临时文件,解压缩,调整大小和压缩图像)。我们正试图将其集成到“无服务器”的Web应用程序中,并且看到我们的代码仅在我们对Azure函数进行测试时才在Windows上运行。CPU,RAM和I/O密集型代码在Azure功能上运行缓慢

我们观察到,我们的代码在Azure功能上的运行速度远远低于本地工作站(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“App Service”计划中的相同工作花费了117到119秒,在我的工作站上花费了大约31秒。

P3上的计时与S3类似,这与我预期的CPU和RAM规格相同。

所以,我有几个问题真的:

  1. 有什么我们能做的来分析运行在Azure上我们的应用程序,以查明瓶颈可能是什么?
  2. 我们疯狂地试图在Azure函数上运行如此繁重的工作负载吗?
  3. 有没有人有任何建议可以让我们的代码在更强大的硬件上运行,而不会吞噬管理虚拟机场的所有复杂性?
+1

你在哪里写这些文件?请注意,在消费计划中,在d:\ home下的文件系统是从Azure Files安装的,并且具有相当高的I/O延迟。您可以尝试在D:\ local下的本地存储中写入,然后查看是否有差异。此外,在消费计划功能应用程序关联到1核心。你应该扩展出无服务器 – ahmelsayed

+0

谢谢你的提示!我已经检查过,它看起来像我们所有的临时文件都是在D:\ local下创建的,所以应该没问题。我们的代码不是主动并行的,所以我不希望核心关系成为一个问题,但我会尝试在单个核心上本地运行它,并且看看会发生什么。 – Anodyne

回答

0
  1. 您可以分析应用程序服务的应用程序(包括应用功能)远程见this link。我用Kudu,它运作良好。

  2. 真的取决于你的目标。您引用的时间对于某些应用程序来说可以完美无瑕。

  3. 对于SO,这似乎过于宽泛。

更FunctionApp十岁上下的办法是尝试打破你的长期运行的功能分成较小的短期运行的功能,从而打破和潜在的并行化处理。

+0

感谢您的链接 - 我将检查文章并更新,当我有东西要报告。 – Anodyne