本文进行实际测试 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 Read More

本文旨在测试 Python Flask 框架的默认并发能力，即同时能处理多少个请求，以及请求等待队列大致有多大; 并找到如何改变默认并发数。虽然网上或许很容易找到它们的默认并发数，但通过实验的方式可以得到更感性的认识。

本文写作时使用的环境为

1. 测试机器为 MacBook Pro, CPU 6 核超线程，内存 16 Gb
2. JMeter 5.5 -- 连续发送请或压力测试
3. Python 3.10.9
4. Flask 2.2.2

从 JMeter 每半秒发送一个请求，连续发送 1000 个，程序中 API 方法接受到请求后 sleep 800 秒，保证在全部 1000 个请求送出之前一直占着连接，以此来找到同时被处理的请求数目，并且有足够的时间统计当前的 TCP 连接数。在测试极端规模的并发数时，由于在 Mac OS X 很难突破 5000 个线程的限制，这时就让 JMeter 分布到远程 Linux(Docker 或虚拟机) 上执行。

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

成熟的 Web  API 框架总有一款 API 文档与之伴随，当前最知名的莫过于支持 Open API 的 Swagger 了。Python 的 Flask 框架支持 Swagger UI 也有几条路子

1. Flasgger : 好像是 flask-swagger 的 fork
2. flask-swagger: 许久未更新了，不用考虑
3. flask-restful-swagger: 到目前也两年未更新了
4. Flask-RESTPlus 的 Swagger 特性: 真需要用到 Flask-RESTPlus 就可以用它

单纯用 Flask 构建 API 的话，细数起来也就 Flasgger 比较合适，如果甩开 Flask 而用 FastAPI 的话，就不用操心 Swagger 了，因为 FastAPI 原生的支持 Swagger。

本文中我们将体验如何使用 Flasgger, 关于使用方法，在它源码的 README.md 已经描述的很清楚了。Flasgger 提供了以下几种主要的使用方式 Read More

Python 的 Flask 框架能让我们快速的建立一个轻量级的 Web 或 REST API。对于小应用由一个 @app 装饰一撸到底就行，当项目稍具规模或要更清晰就要考虑模块化，于是来到了我们今天的话题，首先是

为什么需要 Blueprint?

比如说我们一定超级简单的 Flask 应用 main.py 的代码如下：

Read More

想要配置好 Apache + mod_wsgi + Flask 问题真是太多了，随便换一个 Linux 发行版，或者不同的 Python 版本就得让 Google 排很多温室气体。Nginx 可以使用 uWSGI 和  Flask 串联起来，配置起来第一直觉好像也不容易，所以打算换一种方式，直接用一个 Python 的 WSGI HTTP Server, 必要的话再往前面加一个反向代理的 Nginx。这里就来试下 Nginx + Gunicorn + Flask  的完整配置。

在 Flask 的官方网站 Deployment Options 提到了各种生产环境下的部署办法，与 Gunicorn 类似的工具还有 uWSGI, Gevent, Twited Web, Hypercorn, Uvicorn, Daphne(来自于 django) Read More

在 Flask 的官方文档 mod_wsgi(Apache), 说来倒是轻巧，实际操作起来不得不时刻要凝视眼前的无数大坑，或许 Linux, Apache 都用上比较新的版本会好一些。而我所用的环境是 AWS 上的 EC2, AMI 镜像发行版用 cat /proc/version 看到的是 Red Hat 7.2.1-2，内核为 4.14。照着 Flask  的官方文档是没做成功的，yum install mod_wsgi 只能安装到 Python2 的模块，pip install mod_wsgi 也不成功，所以只能使用 mod_wsgi 的源码来编译安装。

要能顺利编译过 mod_wsgi, 需要安装 Apache 2.2 和 Python 3.6 的 dev 版本。它的仓库里 Python3 最高版本只有 Python 3.6，要 Python 3.7, 3.8 可从源码编译安装。 

$ yum install gcc
$ yum install httpd-devel
$ yum install python36-devel

Red Hat 7.2 下的 Apache 真心的难用，不叫 Apache2 也不叫 httpd2，不像 Debian 系统下的 Apache2 做了模块化，基本上 Red Hat 7.2 的 httpd 的配置全在一个文件中 /etc/httpd/conf/httpd.conf。 Read More

本来只是为了研究一下 Flask  怎么去支持早已在 Python 的支持的 coroutine 功能，没想步子越迈越大，直顶到 aiohttp Web 服务器和 Flask  的异步实现版本 Quart。Flask 得费了好一番功夫去获得 EventLoop，可知 aiohttp 和 Quart 的路由方法直接就允许 async 的，那个 EventLoop 自然就在其中。从 async 的路由方法出发去调用别的异步方法就是一件十分轻松的事情。

下面来稍稍体验一下用分别用  aiohttp 和 Quart 实现简单的异步服务器，我们的关注点在它的异步路由。

Read More

源于自己折腾的一个小 Flask 项目中，后台需访问多个 HTTP 服务，目前采用 ThreadPoolExecutor 多线程的方式处理的。但因访问 HTTP 服务有前后关联关系，如得到请求 A 的结果后再访问 B，这似乎用 Promise.then().then() 编程方式更合适些。于是巡着这一路子，翻出 Python 的各种相关部件来，比如 Python 对 coroutine(协程) 的支持，asyncio, 及后面的 async/await 关键子，aiohttp 组件，requests 的 async 替代品有 aiohttp, grequests, 和 httpx，aiohttp  可替代 Flask, 最后竟然找到了一个更彻底的 Flask 的 Async 版本 Quart。 

Python 3.4 引入了 asyncio 模块，基于生成器(yield 和 yield from) 和 @asyncio.coroutine 的方式来支持 coroutine(协程), 到 Python 3.5 后有了 async/await(@asyncio.corouting 替换为 async, yield from 替换为 await) 关键字，协程的实现变得更为简单。Python 3.4  使用 coroutine 的方式我们跳过，直接看
Read More

紧接上一篇 Flask 和 Vue.js 开发及整合部署实例，来体验一下它们与 Bootstrap/BootstrapVue 的集成。漂亮的网站少不得一个好的 CSS 框架，现在有许许多的 CSS 框架可选，纯 CSS 的, 轻量级的, 含 JS 的 CSS 框架，如 Pure, Bulma, Spectre, 国产的 Element 等。而我总觉得 Bootstrap 更是五臟俱全，像 Element 专为 Vue.js 打造的一样，Bootstrap 也有 BootstrpVue 那样一个结晶品。

本文准确的内容应该是关于 Vue.js 与 Bootstrap/BootstrapVue 的话题，与 Flask 没什么事，不过这里呢，还是强拉上 Flask, 由 Flask 的 API 来产生一些数据。

同样是阅读 Flask和Vue.js构建全栈单页面web应用【通过Flask开发RESTful API】的一个实践品。本篇基于 Flask 和 Vue.js 开发及整合部署实例 中的步骤建立的项目 flask-vue-app，方便起见，用了一个新项目名称 flask-vue-bootstrap。记得我们为 Flask 和 Vue.js 分别建立了 backend  和 frontend 两个子项目。 Read More

想做些简单的 Web 工具，首先想到的是 Flask + Vue.js, 当然可以完全用 Flask 自己的页面模板 Jinja2, 但一个网站项目不能享受到像 Vue.js, React 类似框架的灵活性真是太可惜了。于是 Flask 只专注于 API, 页面逻辑全用 Vue.js 的组合就成了我的首选，Flask 方面还能进一步选择 FlaskRESTful 框架。还需做得更漂亮的话，CSS 框架可选择 Bootstrap 或与 Vue 紧密集成的 BootstrapVue, 这是后话。

本文主要参考 Flask和Vue.js构建全栈单页面web应用【通过Flask开发RESTful API】的前部分，英文原文在这里 Developing a Single Page App with Flask and Vue.js。

开发过程中我们可以保持 Flask 和  Vue.js 为单独的两个项目，并启动各自的服务，比如 Flask 是 http://localhost:5000, Vue.js 项目通过 npm run serve 启动在 http://localhost:8080，借助于 node js 的功能，修改 Vue.js 项目的内容能够自动刷新网页。要是开发中把静态文件全放在  Flask 项目中，那么任何对静态文件的修改都必须重启 Flask  服务。虽然 Debug 模式启动的 Flask 在看到它的目录中有任何修改时也能自动重启，但对静态文件的修改重启 Flask 没这个必要性。 

但部署时需进一步整合，最终只需要启动 Flask  服务，而无须两个，方便部署。如果是以 Docker 容器的方式发布，使用 docker-compose 来编排两个容器来发布也还算不错。更专业的部署方式应该是 Vue.js 的静态内容放到专门的 Web 服务器，如  Apache/Nginx 中，Flask 也通过 wsgi 与 Web 服务器集成起来。 Read More