2017-06-06 8 views
1

かなりCPU、RAM、I/O集約的なコードがあります(多数の一時ファイルを作成、解凍、サイズ変更、圧縮します)。我々はこれを「サーバレス」Webアプリケーションに統合しようとしており、Azure関数でテストしている瞬間にWindows上でのみコードが実行されるため、CPU、RAM、I/O集中コードはAzureでゆっくり実行されます。

私たちのコードは、私のローカルワークステーション(Core i7-4790,16GB RAM、SSD)よりAzure関数でかなり遅くなることがわかりました。例えば、ある典型的なワークロードは、私たちにこれらのタイミングを与える: - 一つの特定のジョブは112の間と153秒を変える私たちの時間を与えた

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

我々はまた、「消費」計画に、タイミングが非常に大きく異なることがわかってきました。 S3 "App Service"計画の同じジョブは117〜119秒、私のワークステーションでは約31秒かかりました。

P3のタイミングはS3と似ていました。これは、CPUとRAMの仕様が同じであるため、予想したタイミングです。

だから私は本当にいくつかの質問を持っている:

  1. たちはボトルネックがあるかもしれない場所を特定するために、Azureの上で実行されている我々のアプリケーションをプロファイルするために何かできることはありますか?
  2. Azure関数でこのような重いワークロードを実行しようとしているのは夢中ですか?
  3. バーチャルマシンのファームを管理するすべての複雑さを呑み込まずに、より強力なハードウェアでコードを実行する方法について、他に提案はありますか?
+1

これらのファイルはどこに書いていますか? Consumptionプランでは、 'd:\ home'の下のファイルシステムはAzureファイルからマウントされ、I/Oのレイテンシはかなり高いことに注意してください。代わりに 'D:\ local'の下のローカル記憶域に書き込んでみて、違いがあるかどうか確認することができます。また、消費計画機能では、アプリは1つのコアにアフィニティ化されています。あなたはサーバレスではないスケールアップする必要があります – ahmelsayed

+0

ヒントをありがとう!チェックしたところ、すべての一時ファイルがD:\ localに作成されているように見えるので、OKにしてください。私たちのコードは積極的に並行しているわけではないので、コアアフィニティは問題ではないと思いますが、私はそれを単一のコアでローカルに実行し、何が起こるかを見ていきます。 – Anodyne

答えて

0
  1. あなたはthis linkを参照して、リモートで(機能アプリケーションを含む)のAppサービスアプリケーションをプロファイルすることができます。私はKuduを使い、それはうまくいった。

  2. 本当にターゲットに依存します。あなたの引用がいくつかのアプリケーションでは完全にうまくいくタイミング。

  3. これはあまりにも幅広い質問のようです。

よりFunctionAppっぽいアプローチが小さい短期実行機能にあなたの長時間実行される機能を打破しようとするので、分解し、潜在的に処理を並列化することであろう。

+0

リンクをありがとう - 私は記事をチェックアウトし、何か報告するときに更新します。 – Anodyne

関連する問題