体验 Python FastAPI 的并发能力及线, 进程模型

本文进行实际测试 FastAPI 的并发能力,即同时能处理多少个请求,另外还能接收多少请求放在等待队列当中; 并找到如何改变默认并发数; 以及它是如何运用线程或进程来处理请求。我们可以此与 Flask 进行对比,参考 Python Flask 框架的并发能力及线,进程模型,是否真如传说中所说的 FastAPI 性能比 Flask 强, FastAPI 是否对得起它那道闪电的 Logo。

本文使用 JMeter 进行测试,测试机器为 MacBook Pro, CPU 6 核超线程,内存 16 Gb。

对于每一种类型 Web 服务基本的测试是每秒发送 2 个请求,连续发送 1000 个,500 秒发送完所有请求,程序中 API 方法接受到请求后 sleep 800 秒,保证在全部 1000 个请求送出之前一直占着连接,并有充足的时间对连接进行分析。在测试极端并发数时,由于在 Mac OS X 尽管设置了 ulimit 最多也只能创建 4000 多一点线程,所以在模拟更多用户数时,JMeter 在远程 Linux(Docker 或虚拟机) 上运行测试用例。

请求的 URL 是 http://localhost:8080/?id=${count}, 带一个自增序列用以识别不同的请求, JMeter 的 Thread Group 配置为 Number of Threads (users): 1000, Ramp-up period (seconds): 500 阅读全文 >>

SpringBoot 启用 GZIP 对响应进行压缩

SpringBoot Web 应用默认是不启用响应数据的压缩,对大的文本类型的响应数据进行压缩是十分必要的,如 JSON, XML 等应用数据,甚至是 JS, CSS 等。

早先的 Web 应用基本是要配置一个叫做 GzipFilter 之类的东西,然后判断请求的 Accept-Encoding 是否含有 gzip, 再对需要的 Content-Type 响应类型的数据进行压缩。

在使用了 SpringBoot 之后,在碰到有压缩响应的需求的时候,第一件事情应该要想到是否能通过在 application.properties(或 application.yml) 配置就行。于是查阅 SpringBoot 2.7.x 的帮助文档 Spring Boot Reference Document, 搜索关键字 compression,翻几页就能找到 17.3.6. Enable HTTP Response Compression, 介绍了三个配置项 阅读全文 >>

《HTTP/2 in Action》阅读笔记(一)

本书买来有一段时日了,一直还未开始阅读,关于网络上 HTTP/2 的真实使用状态查到以下信息

  1. 截止 2021 年 1 月 8 日,有 50% 的网站正在使用 HTTP/2,参见 Usage statistics of HTTP/2 for websites
  2. 另一篇介绍 HTTP/2 Adoption 说 2020 年就有 64% Web 请求是基于 HTTP/2 的

得看看我们自己的网站对 HTTP/2 的支持以及使用状况

于此同时,HTTP/3(gQUIC) 也上了议程,作为 HTTP/3 的提议标准的 RFC9114 也于 2022 年 6 月 6 日由 IETF 发布。

本书首先介绍的是关于 HTTP 协议从 0.9 到 1.0, 再到 1.1 的变迁史。

关于 IPv4 和 IPv6

IP 报文的前四位表示协议版本,所以 0100 就是 4。版本 0 ~ 3 是留给实验用的,5 设计为 Intenet 流协议的,例如实时音视频,像 VoIP, 实际上也因为地址数量的限制没被使用。所以就跳到了 IPv6,字节为  0110。后续的 IP 协议版本 7, 8, 9 都被预定了(比如中国的 IPv9 - 冷),所以再有新的 IP 协议版本的放丈是 IPv10 阅读全文 >>

探索 Apache, Tomcat, SpringBoot 对请求数据的解压缩

通常我们都会配置 Web 服务端对响应数据进行压缩,如用 Apache 的 mod_deflate 模块,或配置 Tomcat connector 启用压缩,又或者是在 Java Web 项目中加 Web Filter 来压缩特定的响应数据。这样客户端发送 HTTP 请求时在头中声明如 Accept-Encoding: gzip,服务端就可能会对响应数据进行压缩,同时带上 Content-Encoding: gzip 响应头。

有时候 HTTP Post 的数据太大同样会要求客户端在传输数据之前对请求数据进行压缩,本文主要关注服务端如何自动解压客户端发出的压缩数据。

先以 Apache2 为例,以 Ubuntu 20.04 为例,用命令 apt-get install apache2 安装 Apache 2.4.41, 它自动启用了 mod_deflate 模块。mod_deflate 模块的配置文件 /etc/apache2/modes-enabled/deflate.conf 内容如下

它表示只对以上特定的响应数据类型进行压缩,下面来测试下对 html 内容的压缩 阅读全文 >>

谁说 HTTP GET 就不能通过 Body 来发送数据呢?

当我们被问及 HTTP 的 GET 与 POST 两种请求方式的区别的时候,很多答案是说 GET 的数据须通过 URL 以 Query Parameter 来传送,而 POST 可以通过请求体来发送数据,所以因 URL 的受限,往往 GET 无法发送太多的字符。这个回答好比在启用了 HTTPS 时,GET 请求 URL 中的参数仍然是明文传输的一样。

GET 果真不能通过 Request Body 来传送数据吗?非也。如此想法多半是因循着网页中 form 的 method 属性只有 get 与 post 两种而来。因为把 form 的 method 设置为 post, 表单数据会放在 body 中,而 method 为 get(默认值) 时, 提交时浏览器会把表单中的字符拼接到 action 的 URL 后作为 query parameter 传送。于是乎就有了这么一种假像:HTTP GET 必须通过 URL 的查询参数来发送数据。

其实 HTTP 规范并未规定说 GET 就不能发送 body 数据,在 RFC GET 中只是说

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

只是说 GET 意味着通过 URI 来识别资源。

我也是本着传统上对 GET 与 POST 区别的误解很多年,今天突然意识到 GET 应该可以使用 body, 况且 HTTP 本身是一个纯文本的协议。没有测试就没有 100% 的发言权,所以做了如下的测试 阅读全文 >>

Swift 语言 Server 端开发资料收集

苹果的 Swift 语言第二版预计在今年底开源,届时还可在 Linux 下使用 Swift 语言。试想一下此语言用在服务端 Web 开发也该是个很好的方向,需要实现对  HTTP 协议的支持。

Swift 本身就可以做 Shell 脚本用,所以以 CGI 的方式运行是没问题的,没有第三方相关的框架,可以自己完全输出响应头和体。

我们可以把 Swift 集成到像 Apache 或 Nginx 的 Web 服务器中,要做的工作可能多些,应该要用到 C/C++ 来写 Swift 支持模块。想下我们用这种 URL http://localhost/service/customer.swift 来访问 swift 实现的后台页面。

或者也可以让 Swift 代码像 NodeJs 一样运行,自己启动 HTTP Server。幸运的是我们已经有了 SwifterTaylor,再配之以纯 Swift 的模板实现 GRMustache, 简单开发不在话下。

一旦该语言流行开了,特别是能用在 Linux 平台下,总会有人去实现出对 HTTP 协议的支持,再配之以模板,让 Swift 像 PHP 一样在 Apache 中运行就不难了。 阅读全文 >>

如果要给 RESTful 每种 HTTP Method 类型指示一种颜色

RESTful 时需要考虑每种 HTTP Method 操作的业务含义,再也不是 GET 使用 URL, POST 提交表单这样简单的区别。http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 定义有 GET, POST, PUT, HEAD, DELETE, PATCH, OPTIONS, TRACE, CONNECT 九种类型的 HTTP Method。

关于它们可能针对的业务含义就不多说了,而是如果要对每一种操作方法赋予一个颜色应该怎么去对应呢,比如一般 GET 不会有边际效应的操作可以选择绿色,或者蓝色。幸好我也不用多想,这里参考了 Swagger 的颜色方案,它支持除 OPTIONS, TRACE 和 CONNECT 之外的颜色配置,其实我也没用过这两种方法。

从 Play2 Swagger 中截图如下: 阅读全文 >>

RESTful, 说说 http 的 patch method

最早的时候,我们只需要 GET 和 POST 方法,POST 方法的引入也只是为了消除 URL 过长,参数隐藏,上传文件的问题,完全和语义无关。接触到 RESTful 之后,我们开始思考 GET 和 POST 的不同语义,并且十分必要的去发掘出所有的 HTTP method,HTTP/1.1 所实现的 method,见 RFC 2616, 有这些:

OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT

规范是这么定义的,这还要看容器实现了多少,比如 Tomcat 7 中的 servlet api 实现了

doOptions, doGet, doHead, doPost, doPut, doDelete, doTrace 就差个 doConnect 了。

而我们这里要说的 PATCH method 是在 Servlet 3.0 和当前 Tomcat 7 中都提到的,也就是尚未实现它。

这也难怪,PATCH 在 2010 年三月份才成为正式的方法,见 RFC 5789。没有 PATCH 的时候我们进行更新的操作采用的是 PUT 方法。那么 PATCH 和 PUT 有什么区别呢?

同样可以从语义上去理解,有两方面的对比: 阅读全文 >>

http上传文件深度解析-高性能http传输

最近在做web服务器的时候将一些应用集成在了服务器里面,比如说文件上传,结果调试用了一个星期的时间,搞得自己头昏脑涨,现在总于解决了,现将注意细节叙述如下: http上传协议很简单,用post协议,协议头部包含Content-Length项,这是一次上传的所有body部分长度总和,包括多文件之间的分割等等,所以也就难怪了,http上传要比ftp等慢,其实慢就慢在body解析上,下面对于文件分割作一些阐述。 一个典型的http上传协议头类似于这样:

POST /public/upload.action HTTP/1.1
ost: maiit.com:8088
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514                  Firefox/3.0b5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 阅读全文 >>