2017-06-06 49 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