5
私は、サービスバストピックによってトリガーされる消費計画で実行されているazure関数を持っています。次にキューに別のメッセージを追加するだけです（基本的にはIOは処理されません）。トリガートピックは〜1000 /秒の割合で満たされています。私は単純に機能が容易にペースを維持できると考えていましたが、実際には絶望的に圧倒されており、トピックの購読は非常に迅速に完了しています。私はそれが完全にスケールアウトされていると思われるので、何時間も実行している。ぼんやりした関数からスケーラビリティがあまりにも大きいと思いますか？
機能からどれくらいのパフォーマンスを期待できますか？スループットは1秒あたり何千というオーダーであるのでしょうか？
編集：私は定期的にログにこのエラーを見ています：
接続試行は00:00:00の時間スパン続きました。 TCPエラー コード10013：アクセス許可によって禁止された方法でソケットにアクセスしようとしました。
サービスバスのように機能していないようですか？これで
public static async Task Run(BrokeredMessage msgin, Binder binder, TraceWriter log)
{
var collector = await binder.BindAsync<IAsyncCollector<BrokeredMessage>>(
new ServiceBusAttribute("my-queue"));
...
}
を：：このバインディングの交換ソリューション ため
編集2
public static IAsyncCollector<BrokeredMessage> collector;
public static async Task Run(BrokeredMessage msgin, Binder binder, TraceWriter log)
{
collector = collector ?? await binder.BindAsync<IAsyncCollector<BrokeredMessage>>(
new ServiceBusAttribute("my-queue"));
...
}
は、ソケットの枯渇を防止し、機能がプロデューサー問題なくペースを維持することができました。
このソリューションは私のために働いた、私は上記の詳細を追加しました。 –