さまざまな数の許可されたスレッドで実行されているマルチスレッド プログラムをプロファイリングしています。以下は、同じ入力作業を 3 回実行したときのパフォーマンス結果です。
1 thread:
Total thread time: 60 minutes.
Total wall clock time: 60 minutes.
10 threads:
Total thread time: 80 minutes. (Worked 33% longer)
Total wall clock time: 18 minutes. 3.3 times speed up
20 threads
Total thread time: 120 minutes. (Worked 100% longer)
Total wall clock time: 12 minutes. 5 times speed up
同じ作業を行うのにより多くのスレッド時間がかかるため、スレッドがリソースをめぐって競合しているに違いないと感じています。
アプリ マシンとデータベース サーバーの両方で、4 つの柱 (CPU、メモリ、diskIO、ネットワーク) を既に調べました。メモリは元の競合リソースでしたが、現在は修正されています (常に 1G 以上の空き容量があります)。CPU は、20 スレッドのテストで 30% から 70% の間で推移しているので、十分です。diskIO は、アプリ マシンでは実質的にゼロであり、データベース サーバーでは最小限です。ネットワークは本当に素晴らしいです。
また、redgate を使用してコード プロファイリングを行いましたが、ロックを待機しているメソッドはありません。スレッドがインスタンスを共有していないことが役立ちます。現在、データベース接続の確立/プーリングなど、より微妙な項目をチェックしています (20 個のスレッドが同じデータベースに接続しようとした場合、それらは互いに待機する必要がありますか?)。
20 スレッドの実行が次のようになるように、リソースの競合を特定して対処しようとしています。
20 threads
Total thread time: 60 minutes. (Worked 0% longer)
Total wall clock time: 6 minutes. 10 times speed up
その競合を見つけるために調べる必要がある最も可能性の高い情報源 (ビッグ 4 以外) は何ですか?
各スレッドが実行するコードは、おおよそ次のとおりです。
Run ~50 compiled LinqToSql queries
Run ILOG Rules
Call WCF Service which runs ~50 compiled LinqToSql queries, returns some data
Run more ILOG Rules
Call another WCF service which uses devexpress to render a pdf, returns as binary data
Store pdf to network
Use LinqToSql to update/insert. DTC is involved: multiple databases, one server.
WCF サービスは同じマシン上で実行されており、ステートレスであり、複数の同時要求を処理できます。
マシンには 8 つの CPU があります。