問題タブ [azure-durable-functions]

クラッシュするようには見えない耐久性のある関数がありますが、最初の呼び出しの後、同じ関数を実行し続けます。この最初の呼び出しの後、ブレークポイントを設定しようとしても効果がありません。

影響があるように見える唯一の要因は、65kb の制限を下回っていますが、リクエスト ペイロードのサイズです。

ドキュメントで説明されているように、ファンアウト/ファンイン パターンを使用しています。タスク配列のサイズが ~100 になると、動作が停止し、無限サイクルに入るように見えます。

ファンアウトの制限を超えたのではないでしょうか? 関数の「インスタンス」の数を制御する方法はありますか?

従量制プランを利用しています。

この動作を停止する唯一の方法は、ローカル ストレージ エミュレーターを停止し、基になる localdb を削除して再初期化することです。

さらにトラブルシューティングを行うための提案はありますか?

Azure で最初の大きな Durable Function を作成しました。ドキュメントのページごとに約 12 のアクティビティ関数を実行します。先日、最大で 5000 ページを処理しました。各アクティビティがワークアイテム Q にアイテムを配置することを理解しているので、理論的には 60k のキュー メッセージを書きましたが、これも読み取る必要があるため、120k アクションになります。

北ヨーロッパ LRS GPv2 ストレージは £0.003/10,000 クラス 2 Q アクション

これは 12 * £0.003 = 3.6p ですが、私のサブスクリプションでは 90p 以上のクラス 2 Q アクションが表示されるため、1 ページあたり 3M Q 操作または 600 Q アクションに相当します。これは、問題の日の 29p であった同じ期間の従量課金プランでのコンピューティング コストを大幅に上回りました。Qに行く必要がある他のメッセージがあることを感謝しますが、これほど多くは期待していませんでした!

Durable Functions が Q をどのように使用しているかという点で何か不足していますか? 生成されたすべての Q (コスト) アクションを 1 つのページでカウントするために調べたり監視したりできるものはありますか?それらを減らします。

私は耐久性のある機能が大好きですが、ストレージのコストが法外になり始めているので、洞察に感謝します! コストを削減するために v1 に移行する予定ですが、これが単なる関数のコストなのか、それとも自分の関数で非効率的なことを行っているのかを知るために、これを理解したいと考えています。

更新 3 おそらく最も有用

ファイルを取得するだけの新しいバージョンを作成し、1 つのアクティビティでそれを単一ページの PDF に分割し、各ページを別のアクティビティで処理して png に変換します。新しいストレージ アカウントを作成し、すべてのログ オプションをオンにすると、ログ ログが最も便利であることがわかりました。100 ページの PDF をアップロードし、関数が実行された期間のログをダウンロードして分析すると、次のようになりました。

ログファイルから見た 10:31 から 10:43 までのおおよその処理:

これ以外では、アプリをアイドル状態のままにして（消費プランで）、1時間ごとに約次のように表示されます。

(ここで最終ログが欠落している可能性があります。10 秒ごとに各タイプのメッセージで 5 つの Q のそれぞれをポーリングしていると思います。そのため、1 時間に 3600 Q アクションになると思います。処理のために何も送信されていませんか?)

関数が実際に何かを実行している間に異常な量の GetMessage と GetMessages が起動されているように思えます。ログを調べて、問題の診断に役立つ場合はログを提供できます。

(関連する場合、インスタンス数は終了するまでに 0 から 8 になりました。インスタンスと豊富な Q リクエストの間に相関関係があるかどうか疑問に思っています)

更新 1

そこで、問題の日のすべての関数呼び出しが得られることを期待して、次を実行しました。

これにより、合計で 19,939 になりました。これは、複数の関数がありますが、実際に約 3,500 ページを処理したページごとに呼び出されるのはそのうちのいくつかだけであるため、ほぼ正しいです。

次に、そのストレージ アカウントで Q のメトリックをクエリする方法を見つけました。フィルターを作成すると、すべての Q トランザクションが送信された次の場所が見つかりました。

ばかげた量の Q 読み取りのように見えますか? 確認するために、私も調べたところ、Q と 25K に置かれたメッセージの量はほぼ正しいようです。

それ以来、V1 ストレージ アカウントに移行し、今日約 8K ページの別の実行を試みたので、すべてのメトリックがストレージ アカウントのメトリックにフィルターされたときにメトリックがどのように見えるかを確認します。

注: チャートを見ると、13 日のデータの方が適切であることがわかります。多くのデータを生成していたため、アプリのインサイトのサンプリングをオンにする以外に、重要な変更はないと思います。

更新 2昨日、新しい v1 ストレージ アカウントで処理された 8k っぽいページで、同様に膨大な数が見られました。

前のアクティビティ関数によって決定された入力を持つ永続的な関数があります。アクティビティ関数ごとに、各タスクが前のタスクの出力に依存する複数の待機可能なタスクがあります。

これは次のような私の構造です：

オーケストレーター

活動機能

私はこれをテストしましたが、すべて正常に動作します。しかし、これが良い習慣かどうか疑問に思っていますか？耐久性のある関数のアクティビティ関数内に待機可能なタスクがあるのは正常ですか?

サブオーケストレーションを呼び出すオーケストレーター関数があり、それがアクティビティ関数を呼び出します。何らかの理由でアクティビティ関数が複数回呼び出されました。

「KMA-Orch-DataRefreshOrchestration」 -> 「KMA-Orch-DataRefreshSubOrchestration」 -> 「KMA-Product」

• Azure ランタイム バージョン: 1.0
• FUNCTIONS_EXTENSION_VERSION : ~1
• 地域 : 米国中部

• ホスティングプラン：スタンダード

• 元のトリガー時間: 2018-07-06 08:00:30,989

• 2 回目のトリガー: 2018-07-06 08:15:41,814
• 3 回目のトリガー: 2018-07-06 08:43:27,074