基准测试表明, Async Python 远不如同步方式
大多数人都知道 async Python 具有更高的并发性。这意味着对于常见的任务如动态网站或 Web API, async 性能更好。
但遗憾的是,async 对于 Python 解释器来说,并不是一个加速条。
在现实条件下的数据(见下图),异步网络框架的吞吐量(请求量/秒)更差,响应延迟也大得多。
基准结果
我测试了各种不同的同步和异步的 Web 服务器配置。
第 50 和 99 分位数的响应时间单位是毫秒, 吞吐量单位是每秒请求量。该表按 P99 排序,我认为这可能是现实世界中最重要的统计指标。
一些注意事项:
表现较好的是同步框架
但 Flask 的吞吐量比其他的要低
表现差的全都是异步框架
异步框架的响应延迟也差很多
基于 Uvloop 的循环比内置的 asyncio 循环做得更好。
如果不得不使用 asyncio,请选择 uvloop。
这些基准测试有代表性吗?
我认为如此,我尽量让基准运行的场景贴近真实,下面是使用的架构。
我尽可能地模拟真实世界的部署:一个反向代理,中间是 Python 代码,后面一个数据库。我还使用了数据库连接池,这是真实的 Web 应用部署中常见的做法(至少对于 来说是这样)。
测试的应用程序通过随机 key 查询数据库某一行,并以 JSON 形式返回。完整的源代码可以参看 github :
https://github.com/calpaterson/python-web-perf
为什么工作进程 worker 数设置不一样?
决定较佳 worker 数量是多少的规则很简单:对于每个框架,我从 1 个 worker 开始,连续增加数量,直到性能变差。
Async 和 sync 框架的较佳 worker 数量在有所不同,原因很简单,async 框架由于其 IO 并发性,一个 worker 进程就能让一个 CPU 跑满。
而同步 worker 就不一样了,它们做 IO 时会调用阻塞,直到 IO 完成。因此,它们需要有更多的 worker,以确保在负载时所有 CPU 核心始终处于满负荷状态。
关于这方面的更多信息,请参见 gunicorn 文档。
一般来说,我们建议 (2 x $num_cores) + 1 作为开始的 worker 数量。虽然这个公式并不太科学,但它是基于这样的假设:对于一个给定的 core,当一个 worker 在处理请求时,另外一个 worker 可以从套接字中读写数据。
机器规格
我在 Hetzner 的 CX31 机器类型上运行了基准测试,它是一个4 vCPU / 8 GB 内存的机器,运行在 Ubuntu 20.04 上。在另一个(较小的)虚拟机上运行了施压程序。
为什么 async 表现更差?
吞吐量
吞吐量(即:请求量/秒)最主要的因素不是 async 还是 sync,而是有多少 Python 代码被替换成了本地代码。简单的说,你能替换的对性能敏感的 Python 代码越多,性能就越好。这是 Python 性能战术,历史悠久(另见:numpy)。
Meinheld 和 UWSGI(每个约 5.3k请求量/秒)包含了大量的 C 代码。标准 Gunicorn(约 3.4k请求量/秒)基于纯 Python。
Uvicorn + Starlette(~4.9k请求/秒)比 AIOHTTP 的默认服务器(~4.5k请求量/秒)替换了更多的 Python 代码(尽管 AIOHTTP 也安装了它的可选 "加速")。
延时
在响应延迟上,问题更复杂。在请求负载下,async 的表现很糟糕,延迟开始飙升,比传统的同步部署,延迟的程度要大得多。
为什么会这样呢?在 async Python 中,多线程是合作式(co-operative)的,简单来说就是线程不被中央治理者(比如内核)打断,而是要主动把执行时间让给别人。在 asyncio 中,执行时间是在三个语言关键词上让渡的:await、async for 和 async with。
这意味着执行时间并不是 "公平 "分配的,一个线程在工作时可能会无意中饿死另一个线程的 CPU 时间。这就是为什么延迟比较不稳定的原因。
相比之下,传统的同步 servers,比如 UWSGI,使用的是内核调度器的抢占式(Pre-emptive)的多进程,它的工作原理是通过周期性地将进程从执行中交换出来,以保证公平性。这意味着时间的分配更加公平,延迟差异更低。
为什么其他基准显示的结果不同?
大多数其他基准(尤其是那些来自 async 框架作者的基准)根本没有为同步框架配置足够的 worker。这意味着,这些同步框架实际上无法合理使用真正可用的大部分 CPU 时间。
下面是 Vibora 项目的一个样本基准(我没有测试这个框架,因为它是一个不太流行的框架)。
Vibora 声称比 Flask 高出 500% 的吞吐量。然而,当我审查他们的基准代码时,发现他们错误地将 Flask 配置为每个 CPU 使用一个 worker。当我纠正这个问题时,得到了以下结果。
使用 Vibora 比 Flask 的吞吐量优势其实只有 18%。Flask 是我测试过的吞吐量较低的同步框架之一,所以我认为一个更好的同步设置会比 Vibora 快得多,尽管这个图看起来令人印象深刻。
另一个问题是,许多基准都会去掉响应延迟的统计数据,而倾向于吞吐量结果(例如 Vibora 的基准甚至没有提到它)。然而,增加吞吐量其实可以通过简单增加机器来提高,但在高负载下的延迟不佳的话并没有直接的解决办法。
只有在延迟在可接受的范围内,提高吞吐量才真正有意义。
进一步的推理、假设和传闻
虽然基准测试在设计方面尽量接近现实,但它仍然比现实生活中的工作负载要单调得多 —— 所有的请求都会做一个数据库查询,都会用这个查询做同样的事情。真实的应用通常会有更丰富的变化:会有一些慢的以及快的操作,一些请求做了很多 IO,另外一些使用了很多 CPU。似乎有理由假设(根据我的经验也是如此),在真实的应用中,延迟变化实际上要高得多。
在这种情况下,我的预感 async 应用的性能会更有问题。公开的传闻与这个想法一致。
Dan McKinley 分享了他在 Etsy 管理一个基于 Twisted 系统的经历。似乎那个系统受到了延迟变大的困扰。
[Twisted的顾问]说,虽然 Twisted 在整体吞吐量上很好,但冷僻的访问请求可能会出现严重的延迟,这对 [Etsy的系统] 来说是个问题,因为 PHP 前端的使用方式是每个 web 请求都会访问几百或几千次。
SQLAlchemy 的作者 Mike Bayer 在几年前写了《异步 Python 和数据库》(1),他在书中从一个稍微不同的角度考虑了异步的问题。他还进行了基准测试,发现 asyncio 的效率较低。
https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/
Rachel by the Bay 写了一篇文章《我们必须谈谈 Python、Gunicorn、Gevent 这件事》(1),文章中描述了基于 gevent 配置所产生的操作混乱。我也曾在生产中遇到过 gevent 的麻烦(虽然与性能无关)。
https://rachelbythebay.com/w/2020/03/07/costly/
我还需要提到的一件事是,在设置这些基准的过程中,每一个 async 实现都最终以一种令人讨厌的方式挂掉。
Uvicorn 的父进程在没有终止任何子进程的情况下就退出了,这意味着我不得不去寻找那些还在 8001 端口的子进程。有一次,AIOHTTP 抛出了一个与文件描述符有关的内部严重错误,但它并没有退出 (因此任何进程监控脚本都不会重新启动它 —— 这可是大罪!)。Daphne 也在本地遇到了麻烦,但我忘了具体是怎么遇到的。
所有这些错误都是短暂的,用 SIGKILL 很容易解决。但实际我不想在生产环境中负责基于这些库的代码。相比之下,我在使用 Gunicorn 或 UWSGI 时没有遇到任何问题 —— 除了UWSGI 在应用没有正确加载时不会退出。
总结
我的建议是:出于性能的考虑,使用普通的、同步的 Python 即可,但尽量使用 native 代码。对于 webserver 来说,如果吞吐量是最重要的,值得考虑 Flask 以外的框架,但即使是 UWSGI 下的 Flask, 也有较好的延迟特性。
感谢 Tudor Munteanu 帮忙检查了文章中的数据。
参阅
Flask 作者已经写过几篇文章,表达了他对 async 的担忧,第一篇是《我不理解 Python 的 asyncio》(1),对 async 技术做了非常好的解释,最近又发了《我感觉不到 async 的压力》(2),里面提到async/await 非常好,但它鼓励大家写一些负载变大后出现灾难性结果的东西。
https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
https://lucumr.pocoo.org/2020/1/1/async-pressure/
《你的函数是什么颜色》这篇文章解释了一个语言如果同时存在同步和异步,开发起来比较痛苦的一些原因。
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
函数着色是 Python 中的一个大问题,现在社区很悲哀地分成了写同步代码的人和写 async 代码的人 —— 他们不能共享同一个库。更糟糕的是,一些异步库还与另外一些异步库不兼容,所以异步 Python 社区更加分裂。
Chris Wellons 最近写了一篇文章,其中也提到了延迟问题和 asyncio 标准库中的一些注脚。不幸的是,这是一种让异步程序更难搞好的问题。
https://nullprogram.com/blog/2020/05/24/
Nathaniel J. Smith 有一系列关于 async 的精彩文章,推荐给有兴趣的读者。
Notes on structured concurrency https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Some thoughts on asynchronous API design in a post-async/await world https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/
Control-C handling in Python and Trio https://vorpus.org/blog/control-c-handling-in-python-and-trio/
Timeouts and cancellation for humans https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
他认为 asyncio 库的概念是错误的。我担心的是,如果讨论 PEPs 规范的那些前辈们都搞不清楚,像我这样的普通开发者就更没戏了。
英文原文:
http://calpaterson.com/async-python-is-not-faster.html
声明:文章收集于网络,版权归原作者所有,为传播信息而发,如有侵权,请联系小编删除,谢谢!
时间:2020-06-21 17:46 来源: 转发量:次
声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。
相关文章:
相关推荐:
网友评论:
最新文章
热门文章