neoblackcap

我觉得很难，毕竟之前有 CentOS 透露过，自己编译的产物的确性能上不如 Redhat 的。因此我觉得编译参数这东西应该是不能作为违反 GPL 的证据

@evilStart 谷歌家有自研的 IDE Cider ，结合他们自己强悍的搜索功能，真的只是写代码就可以了。写完代码就分布式编译，回归测试，打包
应该本质上跟 vscode 差不多，不过其背后是谷歌自家的基础服务支撑，哪怕开源使用体验也是达不到他们家的水平

wsgi 模型不支持你这玩，你要这样玩，其实是要求 wsgi server 支持进程管理。uwsgi 可以帮到你。也许 asgi 也可以做到，不过得看你的代码，如果按 wsgi 模式写的同步代码，建议上 uwsgi 解决这个订阅问题就算了。事实上相当于两个独立进程

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

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

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

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

WX: bmVvX2JsYWNrY2Fw