用 Python 实现每秒处理 120 万次 HTTP 请求

用 Python 做到，每秒处理上百万次 HTTP 请求，可能吗？也许不能，但直到最近这已成为现实。

很多公司都在为了提升程序的执行性能和降低服务器的运营成本，而放弃 Python 去选择其它编程语言，其实这样做并不是必须，因为 Python 完全可以胜任这些任务。

Python 社区最近做了大量关于性能的优化。CPython 3.6 重写了新的字典从而全面提升解析器的执行性能。由于引入更快的调用规则和字典查询缓存，CPython 3.7 甚至还要更快。

我们可以用 PyPy 的 Just-in-Time 来编译复杂的科学计算任务，NumPy 的测试套件也优化了和 C 扩展的兼容性，同时 PyPy 还计划于今年晚些时候做到和 Python 3.5 保持一致。

这些振奋人心的变化激励着我想要有所创新，Python 所擅长的领域众多，我选择了其中一个：Web 和 MicroServices 开发。

了解 Japronto！

Japronto 是一个全新的，为微服务量身打造的微框架。实现它的主要目标包含够快、可扩展和轻量化。的确它快的吓人，甚至远比 NodeJS 和 Go 还要快的多的多。要感谢 asyncio，让我可以同时编写同步和异步代码。

Python 的微框架(蓝色)、NodeJS 和 Go (绿色) 和 Japronto (紫色)

勘误表：用户 @heppu 提到，如果谨慎点用 Go 的 stdlib HTTP 服务器可以写出比上图的 Go 快 12% 的代码。另外 fasthttp 也是一个非常棒的 Go 服务器，同样的测试中它的性能几乎只比 Japronto 低 18%。真是太棒了！

细节优化过程

当一堆小的 GET 请求被客户端以流水线打包发送过来，服务器端很可能只需要一次系统调用，读取一个 TCP 数据包就能拿到全部的请求。

系统调用，以及在内核空间到用户空间之间移动数据，相比起在进程内部移动数据，成本要高的多。这就是为什么不到万不得已，要尽可能少做系统调用的次数。

当 Japronto 收到数据并成功解析出请求序列时，它会尝试尽可能快的把这些请求执行完成，并以正确的顺序合并所有结果，然后只执行一次系统调用发送数据给客户端。实际上因为有 scatter/gather IO 这样的系统调用，合并的工作并不需要自己去完成，只不过 Japronto 暂时还没有用到这些功能。

然而事情并不总是那么完美，有时候请求需要耗费很长时间去处理，等待完成的过程增加了不必要的延迟。

当我们做优化时，有必要考虑系统调用的成本和请求的预期完成时间。

经过优化 Japronto 拿到了 1,214,440 RPS 的成绩

除了利用客户端流水线请求，和优化调用，还有一些其它可用的技术。

Japronto 几乎都是用 C 写的。包含解析器、协议、链接管理、路由、请求、应答等对象都是用 C 扩展写的。

Japronto 力图做到 Python 的懒加载，比如，协议头的字典只有在被试图请求到时才会被创建，另外一系列的对象也只有在第一次使用时才会被创建。

Japronto 使用超牛逼的 picohttpparser C 库来解析状态、协议头以及分片的 HTTP 消息体。Picohttpparser 是直接调用现代 CPU 集成的 SSE4.2 扩展文本处理指令去快速匹配 HTTP 标记的边界(那些 10 年前的老 x86_64 CPU 都有这玩意儿)。I/O 用到了超棒的 uvloop，它是一个 libuv 的封装，在最底层，它是调用 epoll 来提供异步读写通知。

Python 是有垃圾收集功能的语言，为避免不必要的增加垃圾收集器的压力，在设计高性能系统时一定要多加注意。Japronto 的内部被设计的尝试避免循环引用和尽可能少的分配、释放内存，它会预先申请一块区域来存放对象各种，同时尝试在后续请求中重用那些没有被继续引用的 Python 的对象，而不是将那些对象直接扔掉。

这些预先申请的内存的大小被固定为 4KB 的倍数。内部结构会非常小心和频繁的使用这些连续的内存区域，以减少缓存失效的可能性。

Japronto 会尽可能避免不必要的缓存间复制，只在正确的位置执行操作。比如，在处理路由时，先做 URL 解码再进行路由匹配。