异步任务用 asyncio 比 thread 会节省多少性能？

[miniyao]

任务量不算很大，用不上专门的队列。每次任务大约耗时 5 秒左右，一分钟任务总次数 10 次以内，单机性能还可以不算很紧张。

选用 thread 和 asyncio 异步处理都能完成任务，涉及到网络 IO，所以 2 者实际完成任务是时间差别不大。不知道这种任务负荷，长期下来，thread 和 asyncio 对比，asyncio 能节省多少 cpu 及内存性能？有经验的朋友说下吗

[SD10]

是提升性能吧，同步 IO 的话 CPU 会在等着，异步在同一个线程内提高 CPU 利用率，由代码控制，thread 是用操作系统轮转来提高利用率，纯粹比 CPU 利用率效率要低，但是适合并行。所以得看你任务的 IO/ 计算 比例啊。

[miniyao]

@SD10 是的，考虑相比能提升多少性能。任务对 cpu 计算消耗不大，主要是等外部 api 计算完成返回后，再在本地简单处理一下数据就可以。

[alamaya]

你这个任务频率和执行时间，单线程阻塞都搞定了，搞这些花里胡哨的好像没啥意义

[miniyao]

@alamaya 阻塞肯定不行啊，让用户等 5 秒钟的页面，肯定要被批的

[cwjokaka]

任务少的话，两者基本没差别，多的话异步优势会体现出来

[littlewing]

看需要多少个线程，如果太多，几千或上万，就用异步

[luozic]

测试环境用来 benvhmark 跑一下；不同具体业务实现 结果本来就不同

[ipwx]

@miniyao 无论是不是用 asyncio，用户都得等那个请求五秒。只不过前端可以显示读秒而已

[Allianzcortex]

@ipwx 加个 loading 的 gif 转啊转😘

[iPhoneXI]

任务量小没区别，选代码量少容易开发维护的方式

[iPhoneXI]

@iPhoneXI 线程的话，可以用 concurrent.futures，写起来方便，也容易和 asyncio 集成

[wzwwzw]

如果项目初期没有用 asyncio 的话，还是不要选 asyncio 吧。

[skinny]

感觉 asyncio 并不好用，对我来说它有点鸡肋，使用上很复杂，效率提升也不明显，它的高级 API 拖慢了性能，低级 API 又太复杂，我感觉它的低级 API 比那种 callback 模式的更难用更难理解。

如果非常在乎性能也不会用 Python，稍微只是想改进效率的话还要异步编程有其它第三方库，如果是重头开始用 Python 写我更倾向多线程。

[qiyuey]

有过压测，全异步情况下 QPS 提升 30%的同时，CPU 使用率降低 15%。

[artandlol]

建议用 goroutine 性能反而高些

[LokiSharp]

cpu 密集换个语言开发比较合适

[ClericPy]

爬虫试过, 内存确实有节省, 不过上千并发以内不太明显, 也就几十兆
对我来说异步更大的好处是编程理念, 而不是那些不太缺的资源...
写的代码不用关心阻塞主线程

[optional]

web 服务请老老实实用队列

[cabbage]

性能不敏感的话不建议 asyncio，对开发侵入性很大，使用不方便，对非异步代码、非异步第三方库的兼容性问题也比较突出。对性能敏感的话都不建议用 Python 了，，，还是觉得 threading 比较符合 Python 的理念

[hspeed18]

两种方式都压测一下看看 qps，内存，cpu 不就一目了然了吗，不要瞎猜。

[so1n]

asynico 一般比 thread 省去了进程切换时的上下文切换

[a719114136]

1 分钟就 10 次而已，各项指标上不会有多大区别。对哪个熟悉用哪个。
对于更多的并发，只有实测才知道

[watsy0007]

基于你说的...建议熟悉的方案快速怼完. 做好异常处理.

过早的优化是万恶之源.

抛开这个, threading 和 asyncio 对 cpu 和内存的性能影响.主要基于看场景. 对于 IO 密集型的. 用 asyncio 比起 threading, 资源利用率更高效. 否则区别不大.
我建议很多
threading 里面 循环 ` await http request` 没啥区别.