task默认对线程的调度是逐步增加的,连续多次运行并发线程,会提高占用的线程数,而等若干秒不运行,线程数又会降低。这样,会影响程序多次运行的效率。

泡泡龙 2015-09-14 08:51:48
task默认对线程的调度是逐步增加的,连续多次运行并发线程,会提高占用的线程数,而等若干秒不运行,线程数又会降低。这样,会影响程序多次运行的效率。

即使使用了TaskCreationOptions.LongRunning参数,依然效率偏低。对于一些固定执行时间的线程,我们可以提高线程池的最小线程数,来显著提高task多线程的效率。

ThreadPool.SetMinThreads(100, 100);

提高最小线程数之后,可以不使用LongRunning参数。



测试结果(2000线程):

状态 时间

没有设置任何参数,首次运行 48s

没有设置任何参数,连续运行多次 15s~12s

未设置最小线程,设置LongRunning 15s

设置最小线程100,未设LongRunning 8s

设置最小线程100,设置LongRunning 16s



以上结果供大家参考。

联系QQ 564955427
...全文
293 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
於黾 2015-09-14
  • 打赏
  • 举报
回复
软件不是魔法,它是基于硬件的 理论上根本不切实际的东西,不是单纯靠软件就能解决的 使用云计算的技术,把工作分配给网络上的其他空闲计算机去执行,才是解决问题的根本
於黾 2015-09-14
  • 打赏
  • 举报
回复
引用 5 楼 liucqa 的回复:
[quote=引用 3 楼 於黾的回复:]如果不明白计算机硬件原理 而只知道线程越多执行越快 那么就会产生一大堆问题的
你说的人人都知道。 你还有别的办法让几千乃至几万个一模一样的工作线程快速完成的好办法吗?这些线程没有依赖和顺序的要求,也没有一定正确结果的要求。只要运行就行。[/quote] 有啊,云计算. 只用一台机器,几千上万的线程,也只能排队慢慢执行. 就好比把一万个工作分配给同一个人做,他不管怎么改变工作效率,也没法很快的把一万个工作都做完
於黾 2015-09-14
  • 打赏
  • 举报
回复
引用 4 楼 liucqa 的回复:
说对了,测试的线程正是没什么正事的线程
如果你启动了100个线程,但是每个线程都在sleep,这根本测试不出真正执行100个任务的线程效率会如何
泡泡龙 2015-09-14
  • 打赏
  • 举报
回复
引用 3 楼 於黾的回复:
如果不明白计算机硬件原理 而只知道线程越多执行越快 那么就会产生一大堆问题的
你说的人人都知道。 你还有别的办法让几千乃至几万个一模一样的工作线程快速完成的好办法吗?这些线程没有依赖和顺序的要求,也没有一定正确结果的要求。只要运行就行。
泡泡龙 2015-09-14
  • 打赏
  • 举报
回复
引用 2 楼 以专业开发人员为伍的回复:
不能允许一下子拥塞地启动过多线程。只有非常简单、没什么事儿可做的线程才有可能能拥在一起开始执行而不会造成恶性循环,但是你让线程池怎知到这些任务可以拥在一起呢? 业务处理任务如果过多地拥在一起启动,就会造成恶性循环,并不会快速完成任务。 难道你测试用的机器CPU有40核吗?不要随便设置为100。
不能允许一下子拥塞地启动过多线程。只有非常简单、没什么事儿可做的线程才有可能能拥在一起开始执行而不会造成恶性循环,但是你让线程池怎知到这些任务可以拥在一起呢? 业务处理任务如果过多地拥在一起启动,就会造成恶性循环,并不会快速完成任务。 难道你测试用的机器CPU有40核吗?不要随便设置为100。[/quote] 说对了,测试的线程正是没什么正事的线程
ajianchina 2015-09-14
  • 打赏
  • 举报
回复
原来你是在搞这些测试,很好啊,多多试验,有什么好的经验希望能及时分享,我顶你。
於黾 2015-09-14
  • 打赏
  • 举报
回复
如果不明白计算机硬件原理 而只知道线程越多执行越快 那么就会产生一大堆问题的
  • 打赏
  • 举报
回复
不能允许一下子拥塞地启动过多线程。只有非常简单、没什么事儿可做的线程才有可能能拥在一起开始执行而不会造成恶性循环,但是你让线程池怎知到这些任务可以拥在一起呢? 业务处理任务如果过多地拥在一起启动,就会造成恶性循环,并不会快速完成任务。 难道你测试用的机器CPU有40核吗?不要随便设置为100。
泡泡龙 2015-09-14
  • 打赏
  • 举报
回复
引用 9 楼 liucqa 的回复:
综合考虑测试的结果,还是采用方案3比较合适:未设置最小线程,设置LongRunning 。这个方案线程不会一次性创建完毕,不会造成大量线程队列,取消线程也不会造成假死。 如果采用方案四,速度最快,但是如果使用taskTokenSource.Cancel(),会产生大量的异常,貌似线程处理不过来,会导致UI假死。
其实可以考虑不抛出异常,直接退出线程,这样就不会搞出大量异常处理的问题了
泡泡龙 2015-09-14
  • 打赏
  • 举报
回复
综合考虑测试的结果,还是采用方案3比较合适:未设置最小线程,设置LongRunning 。这个方案线程不会一次性创建完毕,不会造成大量线程队列,取消线程也不会造成假死。 如果采用方案四,速度最快,但是如果使用taskTokenSource.Cancel(),会产生大量的异常,貌似线程处理不过来,会导致UI假死。
泡泡龙 2015-09-14
  • 打赏
  • 举报
回复
引用 8 楼 Z65443344 的回复:
软件不是魔法,它是基于硬件的 理论上根本不切实际的东西,不是单纯靠软件就能解决的 使用云计算的技术,把工作分配给网络上的其他空闲计算机去执行,才是解决问题的根本
嗯,在没钱的情况下,你还有别的方案吗?谢谢
  • 打赏
  • 举报
回复
task本来就是基于线程池的,不过对于任何验证分享我们都应该赞下
Apache DolphinScheduler是一个新一代分布式大据工作流任务调度系统,致力于“解决大据任务之间错综复杂的依赖关系,整个据处理开箱即用”。它以 DAG(有向无环图) 的方式将任务连接起来,可实时监控任务的运行状态,同时支持重试、从指定节点恢复失败、暂停及 Kill任务等操作。目前已经有像IBM、腾讯、美团、360等400多家公司生产上使用。 调度系统现在市面上的调度系统那么多,比如老牌的Airflow, Oozie,Kettle,xxl-job ,Spring Batch等等, 为什么要选DolphinScheduler ? DolphinScheduler 的定位是大据工作流调度。通过把大据和工作流做了重点标注. 从而可以知道DolphinScheduler的定位是针对于大据体系。 DolphinScheduler是非常强大的大调度工具,有以下一些特点:1、通过拖拽以DAG 图的方式将 Task 按照任务的依赖关系关联起来,可实时可视化监控任务的运行状态;2、支持丰富的任务类型;3、支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复,同时支持失败重试/告警、从指定节点恢复失败、Kill 任务等操作;4、支持工作流全局参及节点自定义参设置;5、支持集群HA,通过 Zookeeper实现 Master 集群和 Worker 集群去中心化;6、支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计;7、支持补,并行或串行回填据。课程带大家构建DolphinScheduler大调度平台,实战讲解多种任务调度配置,基于案例讲解DolphinScheduler使用,让大家在实战中掌握DolphinScheduler。 DolphinScheduler 发展很快 很多公司调度都切换到了DolphinScheduler,掌握DolphinScheduler调度使用势在必行,抓住新技术机遇,为跳巢涨薪做好准备。

110,533

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧