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