nservicebus コードのパフォーマンスを改善する方法を見つけようとしています。nservicebus ホストの実行/インストール時に設定できるこれらのプロファイルを検索して見つけました。
現在、nservicebus ホストをそのまま実行しています。デフォルトでは、利用可能なプロファイルの「Lite」バージョンを使用していると読みました。このリンクからも学びました：
http://docs.particular.net/nservicebus/hosting/nservicebus-host/profiles
Integrated プロファイルと Production プロファイルがあることを確認します。ドキュメンテーションには多くのことは書かれていません。Production プロファイルを試して、nservicebus のパフォーマンスが向上したことに気付いた人はいますか? キューからメッセージを消費する速度に特に影響しますか?
NSB プロファイル間の主な違いの 1 つは、サブスクリプションのストレージを処理する方法です。
lite、統合、および運用プロファイルにより、NSB はその信頼性を構成できます。たとえば、lite プロファイルは、すべての pub/sub 登録にインメモリ サブスクリプション ストレージを使用します。サブスクライバーをライト プロファイルに登録するには、パブリッシャーが既に実行されている必要があるため (パブリッシャーがサブスクライバー リストをメモリに保存できるようにするため)、これは懸念事項です。つまり、パブリッシャーが何らかの理由でクラッシュした場合 (またはオフラインになった場合)、すべてのサブスクリプション情報が失われます (各サブスクライバーが再起動されるまで)。
そのため、開発者のマシンで実行していて、サービスがどのように相互作用するかをすばやくテストしたい場合は、ライト プロファイルが適しています。ただし、他の環境には適していません。
統合プロファイルは、サブスクリプション情報をローカル キューに保存します。これは、単純な環境 (QA など) に適しています。ただし、高度に分散された環境では、サブスクリプション情報をデータベースに保持するのが最適であるため、運用プロファイルが最適です。
したがって、あなたの質問に答えるために、プロファイルを変更してもパフォーマンスが向上するとは思いません。どちらかといえば、ライト プロファイルから他のプロファイルのいずれかに変更すると、パフォーマンスが低下する可能性があります (キューまたはデータベース ストレージにアクセスするコストが発生するため)。
ロギングを自分で調整しない限り、ロギングの削減に基づいて大幅な改善が見られました。キューからの読み取りのパフォーマンスはどこでも同じです。キューはローカルであるため、トランスポートから得られるものはあまりありません。ハンドラーと基盤となるインフラストラクチャの調整を検討します。MSMQ のチューニングを確認し、使用しているディスクなどを確認することもできます。もう 1 つのスポットは、分散トランザクションが必要なリモート データベースを使用していると仮定して、分散トランザクションがどのように機能しているかを調べることです。
処理時間を増やすもう 1 つのオプションは、キューを消費するスレッドの数を増やすことです。これにはライセンスが必要になります。ライセンスがオプションでない場合は、シングル スレッド エンドポイントの複数のインスタンスを実行できます。これには、メッセージの種類などに基づいて作業を分割する必要があります。
スケールアップを続けると、ディストリビューターを使用して作業の負荷を分散できます。これにもライセンスが必要ですが、必要に応じてノードを追加できます。上記の機会はすべて、このトポロジにも適用されます。