为什么这个C＃数据处理应用程序的吞吐量远低于服务器的原始function？
我已经整理了一个小的测试工具来诊断为什么我的C＃数据处理应用程序的吞吐量（它的核心function使用非阻塞IO从远程数据库服务器批量选择100个记录并对它们执行简单处理）远低于它可能是。 我观察到，在运行时，应用程序不会遇到CPU（<3％），网络或磁盘IO或RAM方面的瓶颈，并且不会对数据库服务器造成压力（数据库上的数据集几乎总是完全在内存）。 如果我并行运行应用程序的多个实例，我可以达到~45个实例，延迟仅降低约10％但吞吐量增加45倍，然后数据库服务器上的CPU利用率成为瓶颈（此时，那里仍然没有客户端的资源瓶颈）。
我的问题是，当客户端服务器能够大幅提高吞吐量时，为什么TPL不增加飞行中的任务数量或以其他方式增加吞吐量？
简化代码摘录：
public static async Task ProcessRecordsAsync() { int max = 10000; var s = new Stopwatch(); s.Start(); Parallel.For(0, max, async x => { await ProcessFunc(); }); s.Stop(); Console.WriteLine("{2} Selects completed in {0} ms ({1} per ms).", s.ElapsedMilliseconds, ((float)s.ElapsedMilliseconds) / max, max); } public static async Task ProcessFunc() { string sql = "select top 100 MyTestColumn from MyTestTable order by MyTestColumn desc;"; string connStr = "..."; using (SqlConnection conn = new SqlConnection(connStr)) { try { conn.Open(); SqlCommand cmd = new SqlCommand(sql, conn); DbDataReader rdr = await cmd.ExecuteReaderAsync(); while (rdr.Read()) { // do simple processing here } rdr.Close(); } catch (Exception ex) { Console.WriteLine(ex.ToString()); } } } Parallel For不会试图扼杀处理器的生命，并最大限度地增加为您工作的并发线程数。 它使用核心数作为起点，并可能根据工作负载的性质而增加。 看到这个问题 。
实际上，在打开连接和读取行时，实际上确实有阻塞IO …. 您可以尝试这样做：
//.... using (var conn = new SqlConnection(connStr)) { await conn.OpenAsync(); SqlCommand cmd = new SqlCommand(sql, conn); try { using ( var rdr = await cmd.ExecuteReaderAsync()) { while (await rdr.ReadAsync()) { // do simple processing here } } } catch (Exception ex) { Console.WriteLine(ex.ToString()); } } //...
您的示例可能受限于应用程序中池化SQL连接的最大数量，默认情况下为100。 这可以解释为什么在运行应用程序的多个实例时获得更多吞吐量。 您可以尝试监视SQL Server中的连接数，以查看是否是这种情况。