c# - ThreadPool.QueueUserWorkItem と Task.Factory.StartNew のパフォーマンスの違い

Question

いくつかの場所で使用するコードベースがありますThreadPool.QueueUserWorkItem。スケジューラとしての使用ThreadPool.QueueUserWorkItemからTask.Factory.StartNewwithの使用に切り替えるのは良い考えだと思いました。TaskScheduler.Default

アップグレード後、アプリケーションの実行時間が非常に高くなりました。これはオンラインの国境を越えたアプリケーションであり、要求を受け取り、通常は 40 ミリ秒から 500 ミリ秒で応答します。これは許容範囲です。Tasks 方式に切り替えた後、応答に 4000 ミリ秒から 38000 ミリ秒もかかる多くのトランザクションが見られますが、これは容認できません。

その流れはかなり複雑です。これには、着信トランザクションの同期ループが含まれ、実際には単純な検証とデータベースへの挿入が行われます。その後、いくつかの並列アクションが起動され、メイン ループは次の着信トランザクションに進みます。並列アクションは、主にログ記録と、データのデータベース集中型品質チェックです。

すべてのロギング アクションは、ThreadPool で開始されました。

ThreadPool.QueueUserWorkItem(/*logging action*/)

品質チェック アクションが開始されました

Task.Factory.StartNew(/*qc action*/,
     TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness)

変更を適用した後、ロギング アクションは次のように切り替えられました

Task.Factory.StartNew(/*logging action*/,
     CancellationToken.None,
     TaskCreationOptions.None,
     TaskScheduler.Default)

そして、品質チェックアクションはに切り替えられました

Task.Factory.StartNew(/*qc action*/,
     CancellationToken.None,
     TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness,
     TaskScheduler.Default)

ThreadPoolScheduler (TaskScheduler.Default) で Task.Factory.StartNew を使用して実行すると、ロギング アクションが品質チェック アクションを停止する可能性がありますが、QueueUserWorkItem を使用して ThreadPool で直接実行すると、そうではありませんか?

品質チェック アクションのフラグが、TaskCreationOptions.PreferFairness開始時にこのフラグが設定されていない場合でも、品質チェックがロギング アクションを待機させる可能性はありますか?