新しいWindowsAzure.Storage2.0を使用しており(関連情報ではない可能性があります)、CloudTableClientを使用してデータアクセスを実装しています。私が見たほとんどのサンプルは、ASP MVCコントローラーのctorでCloudTableClientをインスタンス化しています(Web要求ごとにインスタンス化されています)。そうすることでパフォーマンスの低下はありますか?長時間実行されるインスタンスをシングルトンスタイルで維持するのが賢明でしょうか?
4 に答える
リクエストごとにCloudTableClientの新しいインスタンスを作成する必要があります。インスタンスメンバーはスレッドセーフではないため、シングルトンを共有することはできません。
私はこの質問/回答に出くわしました。同じことを疑問に思い、SDKのソースコードを(他の何かのために)調べているときに、何か便利なものに出くわしました。
操作を実行するとき、SDKはHttpClientFactoryを使用しているため、HttpClientの単一の静的インスタンスが再利用されています。これは適切であり、不適切なインスタンス化のアンチパターンを修正するため、シングルトンを使用する一般的な理由はすでにソートされています。
関連するコードは実行中にgithubで見つけることができ
、HttpClientファクトリ は静的に実装されますLazy<T>
特に、Storage SDKはTableをサポートしなくなりました(代わりにCosmos SDKがTableを提供しているようです-私はもっと学んでいます)ので、これはおそらく議論の余地のある観察です。
2020年には再利用すべきだと思います。
https://azure.microsoft.com/en-us/blog/performance-tips-for-azure-documentdb-part-1-2/
CloudTableClientのドキュメントを見ると、スレッドセーフではないことがわかりました。
このタイプのパブリックスタティック(Visual Basicで共有)メンバーはすべてスレッドセーフです。インスタンスメンバーは、スレッドセーフであることが保証されていません。
したがって、リクエストごとにインスタンス化する必要があります。