如何解决在C#中用于大量IO操作的线程类型
我的任务是更新操作中非常单线程的c#应用程序(非gui),并向其中添加多线程以使其更快地完成工作。
每个线程将需要执行非常少量的计算,但是大多数工作将在调用并等待SQL Server请求。因此,与CPU时间相比,有很多等待。
几个要求将是:
- 在某些有限的硬件(即仅几个内核)上运行。当前系统在“推”入时仅占用约25%的CPU。但是,由于它主要是在等待SQL Server响应(不同的服务器),因此我们希望具有比核心更多线程的功能。
- 能够限制线程数。我也不能只拥有无限数量的线程。我不介意通过数组,列表等来限制自己。
- 能够跟踪这些线程何时完成,以便进行一些后处理。
在我看来,.NET Framework有许多不同的线程处理方式,我不确定在此任务中是否有一种方法优于另一种。我不确定是否应该使用Task
,Thread
,ThreadPool
,还有其他一些东西……async
\ await
模型在这种情况下不是很好,因为它等待一项特定任务完成。
解决方法
我不确定是否应该使用Task,Thread,ThreadPool等其他东西...
对于您而言,这比您想像的要重要。您可以专注于最适合您(现有)代码样式和数据流的内容。
因为它主要是在等待SQL Server响应
您的主要目标是使尽可能多的SQL查询并行进行。
能够限制线程数。
不必担心太多。在拥有25%CPU的4核上,您可以轻松拥有100个线程。有关64位的更多信息。但是您不希望有数千个线程。 .net线程至少占用1MB的空间,估计可以节省多少RAM。
因此,这取决于您的应用程序,您可以同时运行多少个查询。首先要担心线程安全。
当并行查询的数量> 1000时,您将需要async / await在更少的线程上运行。
只要它Parallel.ForEach(),Parallel.Invoke()
等看起来像是很好的工具。
100-1000范围是灰色区域。
,为其添加多线程以使其更快地处理工作队列。
每个线程将需要执行非常少量的计算,但是大多数工作将在调用并等待SQL Server请求。因此,与CPU时间相比,有很多等待。
通过这种处理,还不清楚多线程如何使您受益。多线程是并发的一种形式,并且由于您的工作负载主要是受I / O约束的,因此异步(而非多线程)将是首先要考虑的问题。
在我看来,.NET Framework有许多不同的线程处理方式,我不确定在此任务中是否有一种方法比另一种更好。
的确。作为参考,Thread
和ThreadPool
如今已成为传统。有更好的高级API。如果将Task
用作委托任务(例如Task.Factory.StartNew
),也应该很少。
在我看来,异步\等待模型在这种情况下并不适合,因为它等待一个特定任务完成。
await
将一次等待一个任务 ,是的。 Task.WhenAll
可用于合并
多个任务,然后您可以await
处理合并的任务。
让它更快地完成工作队列。
能够限制线程数。
能够跟踪这些线程何时完成,以便我可以进行一些后处理。
在我看来,TPL Dataflow是您系统的最佳方法。数据流允许您定义数据流经的“管道”,其中某些步骤是异步的(例如,查询SQL Server),而其他步骤是并行的(例如,数据处理)。
我在问一个高层次的问题,试图找回高层次的答案。
您可能对my book感兴趣。
,在我看来,异步\等待模型在这种情况下并不适合,因为它等待一个特定任务完成。
那是错的。异步/等待只是一种语法,用于简化异步代码的状态机机制。它等待而不消耗任何线程。换句话说,async
关键字不会创建线程,await
不会保留任何线程。
能够限制线程数
请参阅How to limit the amount of concurrent async I/O operations?
能够跟踪这些线程何时完成,以便我可以进行一些后处理。
如果您不使用“一劳永逸”模式,则只需编写await task
var task = MethodAsync();
await task;
PostProcessing();
async Task MethodAsync(){ ... }
或者对于类似的方法,您可以使用ContinueWith
:
var task = MethodAsync();
await task.ContinueWith(() => PostProcessing());
async Task MethodAsync(){ ... }
了解更多:
Releasing threads during async tasks
,TPL Dataflow库可能是这项工作的最佳选择之一。这是构建一个由两个块组成的简单数据流管道的方法。第一个块接受一个文件路径并产生一些中间数据,这些中间数据随后可以插入数据库中。第二个块通过将它们发送到数据库来消耗来自第一个块的数据。
var inputBlock = new TransformBlock<string,IntermediateData>(filePath =>
{
return GetIntermediateDataFromFilePath(filePath);
},new ExecutionDataflowBlockOptions()
{
MaxDegreeOfParallelism = Environment.ProcessorCount // What the local machine can handle
});
var databaseBlock = new ActionBlock<IntermediateData>(item =>
{
SaveItemToDatabase(item);
},new ExecutionDataflowBlockOptions()
{
MaxDegreeOfParallelism = 20 // What the database server can handle
});
inputBlock.LinkTo(databaseBlock);
现在,每次用户上载文件时,您只需将文件保存在临时路径中,然后将该路径发布到第一块即可:
inputBlock.Post(filePath);
就是这样。数据将从流水线的第一个块自动流到最后一个块,并根据每个块的配置进行转换和处理。
这是一个故意简化的示例,用于演示基本功能。生产就绪的实现可能会定义更多的选项,例如CancellationToken
和BoundedCapacity
,它将监视inputBlock.Post
的返回值以防万一该块不能接受作业,可能有completion propagation,请注意databaseBlock.
Completion
属性中的错误等。
如果您对遵循此方法感兴趣,那么最好对库进行一些研究,以熟悉可用的选项。例如,有一个TransformManyBlock
可用,适用于从单个输入产生多个输出。 BatchBlock
在某些情况下也可能有用。
TPL数据流内置在.NET Core中,并且可以作为package用于.NET Framework。它有一些学习曲线,需要注意一些陷阱,但这并不可怕。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。