neoblackcap

@coolmenu 的确是这样的，这至少说明.net 生态卖闭源组件的确能活下去。

之前看过 rdp 的相关资料，其实 rdp 是会在客户端进行被控制端的 GUI 绘制的。不是直接传输视频的类型，因此如果有观察 windows 下微软的自家实现，可以看到流量的使用并没有那么大。
然后 rdp 其实是微软自家搞的，有微软的专利。没猜错的话，应该是微软那边有特定专利下的高效实现，如果不申请授权大概是没法用。这就导致了为什么 rdp 客户端的体验差别那么大。
如果感觉卡，其实可以换不同的客户端试试

@haoliang 请看我 25 楼的回答，我早以指出所谓的异步调用可以用现有的标准库封装线程池实现。
同时本帖的重点并不是什么异步同步之争，本身问题是基于 Python 环境的。一个底层是线程池封装的异步调用真的会比同步的多线程更高效吗？我表示怀疑

@wamson 你这样说的前提是你的数据库顶得住那么多请求啊，你的数据库明明就只能接收 10 个请求，你这边应用端发 100 个过去，那么你是不是应该有 90 个请求快速返回了，然后报错？切出去 CPU，不就变成用于回来处理这些问题？并不能合理利用 CPU 等待 IO 的时间嘛。要不你说说这个情况如何解决。
我并不排斥异步，但是我觉得异步要分开场景。数据库请求对于异步的要求我觉得不是那么大。很多数据库顶不住你的大量查询请求。

WX: bmVvX2JsYWNrY2Fw

@hjahgdthab750 单单官网底下就说明了该数据库驱动是有连接池在底层的。异步调用的需求肯定是有的，但是这不是必须的，python 还有 asyncpg 。

@wamson 你做过 benchmark 吗？你大量的数据库查询请求是怎么发给数据库的？如果多了要排队，那么跟同步有什么区别？纯粹只是调用的区别嘛，你现在也可以自己简单封装一下，标准库已经有这样的组件可以让你将同步的函数封装成异步的

不是什么都应该是异步的，数据库操作异步，跟线程池有什么区别？又不能提高并发量。本质上只是为了使用者的个人偏好搞异步封装。
实际上这样的做法，我认为会掩盖了事物的根本，到时候出问题，又得去连接池的地方找问题。看了那么多的其他语言实现，数据库驱动这部分，大家基本上都是连接池的一套，同步操作的