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 までのおおよその処理:
203 PutMessage (which makes sense)
203 DeleteMessage
7868 GetMessage - all from the workitems queue
26445 GetMessages - all from the control queues, breakdown was
control-00 - 6217
control-01 - 6375
control-02 - 5134
control-03 - 8719
これ以外では、アプリをアイドル状態のままにして（消費プランで）、1時間ごとに約次のように表示されます。
3500 - GetQueueMetadata - 700 against each Q, control 00-03 and workitems
3500 - PeekMessage - 700 against each Q, control 00-03 and workitems
(ここで最終ログが欠落している可能性があります。10 秒ごとに各タイプのメッセージで 5 つの Q のそれぞれをポーリングしていると思います。そのため、1 時間に 3600 Q アクションになると思います。処理のために何も送信されていませんか?)
関数が実際に何かを実行している間に異常な量の GetMessage と GetMessages が起動されているように思えます。ログを調べて、問題の診断に役立つ場合はログを提供できます。
(関連する場合、インスタンス数は終了するまでに 0 から 8 になりました。インスタンスと豊富な Q リクエストの間に相関関係があるかどうか疑問に思っています)
更新 1
そこで、問題の日のすべての関数呼び出しが得られることを期待して、次を実行しました。
let start = datetime(2018-06-12T00:00:00);
traces
| where timestamp > start and timestamp < start + 24h
| where message startswith "function started"
| summarize count()
これにより、合計で 19,939 になりました。これは、複数の関数がありますが、実際に約 3,500 ページを処理したページごとに呼び出されるのはそのうちのいくつかだけであるため、ほぼ正しいです。
次に、そのストレージ アカウントで Q のメトリックをクエリする方法を見つけました。フィルターを作成すると、すべての Q トランザクションが送信された次の場所が見つかりました。
ばかげた量の Q 読み取りのように見えますか? 確認するために、私も調べたところ、Q と 25K に置かれたメッセージの量はほぼ正しいようです。
それ以来、V1 ストレージ アカウントに移行し、今日約 8K ページの別の実行を試みたので、すべてのメトリックがストレージ アカウントのメトリックにフィルターされたときにメトリックがどのように見えるかを確認します。
注: チャートを見ると、13 日のデータの方が適切であることがわかります。多くのデータを生成していたため、アプリのインサイトのサンプリングをオンにする以外に、重要な変更はないと思います。
更新 2昨日、新しい v1 ストレージ アカウントで処理された 8k っぽいページで、同様に膨大な数が見られました。
