内容简介:关于如何配置 Gunicorn 的实用建议概要,对于 CPU 受限的应用应该提升集群数量或者核心数量。但对于 I/O 受限的应用应该使用“伪线程”。Gunicorn 是一个 Python 的 WSGI HTTP 服务器。它所在的位置通常是在反向代理(如Nginx)或者负载均衡(如AWS ELB)和一个 web 应用(比如 Django 或者 Flask)之间。
关于如何配置 Gunicorn 的实用建议
概要,对于 CPU 受限的应用应该提升集群数量或者核心数量。但对于 I/O 受限的应用应该使用“伪线程”。
Gunicorn 是一个 Python 的 WSGI HTTP 服务器。它所在的位置通常是在反向代理(如Nginx)或者负载均衡(如AWS ELB)和一个 web 应用(比如 Django 或者 Flask)之间。
Gunicorn 架构
Gunicorn 实现了一个 UNIX 的预分发 web 服务端。
好的,那这是什么意思呢?
- Gunicorn 启动了被分发到的一个主线程,然后因此产生的子线程就是对应的 worker。
- 主进程的作用是确保 worker 数量与设置中定义的数量相同。因此如果任何一个 worker 挂掉,主线程都可以通过分发它自身而另行启动。
- worker 的角色是处理 HTTP 请求。
- 这个 预 in 预分发 就意味着主线程在处理 HTTP 请求之前就创建了 worker。
- 操作系统的内核就负责处理 worker 进程之间的负载均衡。
为了提高使用 Gunicorn 时的性能,我们必须牢记 3 种并发方式。
第一种并发方式(workers 模式,又名 UNIX 进程模式)
每个 worker 都是一个加载 Python 应用程序的 UNIX 进程。worker 之间没有共享内存。
建议的 workers
数量 是 (2*CPU)+1
。
对于一个双核(两个CPU)机器,5 就是建议的 worker 数量。
gunicorn --workers=5 main:app 复制代码
第二种并发方式(多线程)
Gunicorn 还允许每个 worker 拥有多个线程。在这种场景下,Python 应用程序每个 worker 都会加载一次,同一个 worker 生成的每个线程共享相同的内存空间。
为了在 Gunicorn 中使用多线程。我们使用了 threads
模式。每一次我们使用 threads
模式,worker 的类就会是 gthread
:
gunicorn --workers=5 --threads=2 main:app 复制代码
上一条命令等同于:
gunicorn --workers=5 --threads=2 --worker-class=gthread main:app 复制代码
在我们的例子里面最大的并发请求数就是 worker * 线程
,也就是10。
在使用 worker 和多线程模式时建议的最大并发数量仍然是 (2*CPU)+1
。
因此如果我们使用四核(4 个 CPU)机器并且我们想使用 workers 和多线程模式,我们可以使用 3 个 worker 和 3 个线程来得到最大为 9 的并发请求数量。
gunicorn --workers=3 --threads=3 main:app 复制代码
第三种并发方式(“伪线程”)
有一些 Python 库比如(gevent 和Asyncio)可以在 Python 中启用多并发。那是基于协程实现的“伪线程”。
Gunicrn 允许通过设置对应的 worker 类来使用这些异步 Python 库。
这里的设置适用于我们想要在单核机器上运行的 gevent
:
gunicorn --worker-class=gevent --worker-connections=1000 --workers=3 main:app 复制代码
worker-connections 是对于 gevent worker 类的特殊设置。
(2*CPU)+1
仍然是建议的 workers
数量。因为我们仅有一核,我们将会使用 3 个worker。
在这种情况下,最大的并发请求数量是 3000。(3 个 worker * 1000 个连接/worker)
并发 vs. 并行
- 并发是指同时执行 2 个或更多任务,这可能意味着其中只有一个正在处理,而其他的处于暂停状态。
- 并行是指两个或多个任务正在同时执行。
在 Python 中,线程和伪线程都是并发的一种方式,但并不是并行的。但是 workers 是一系列基于并发或者并行的方式。
理论讲的很不错,但我应该怎样在程序中使用呢?
实际案例
通过调整Gunicorn设置,我们希望优化应用程序性能。
- 如果这个应用是I/O 受限,通常可以通过使用“伪线程”(gevent 或 asyncio)来得到最佳性能。正如我们了解到的,Gunicorn 通过设置合适的 worker 类 并将
workers
数量调整到(2*CPU)+1
来支持这种编程范式。 - 如果这个应用是CPU 受限,那么应用程序处理多少并发请求就并不重要。唯一重要的是并行请求的数量。因为Python’s GIL,线程和“伪线程”并不能以并行模式执行。实现并行性的唯一方法是增加**
workers
** 的数量到建议的(2*CPU)+1
,理解到最大的并行请求数量其实就是核心数。 - 如果不确定应用程序的内存占用,使用
多线程
以及相应的 gthread worker 类 会产生更好的性能,因为应用程序会在每个 worker 上都加载一次,并且在同一个 worker 上运行的每个线程都会共享一些内存,但这需要一些额外的 CPU 消耗。 - 如果你不知道你自己应该选择什么就从最简单的配置开始,就只是
workers
数量设置为(2*CPU)+1
并且不用考虑多线程
。从这个点开始,就是所有测试和错误的基准环境。如果瓶颈在内存上,就开始引入多线程。如果瓶颈在 I/O 上,就考虑使用不同的 Python 编程范式。如果瓶颈在 CPU 上,就考虑添加更多内核并且调整workers
数量。
构建系统
我们软件开发人员通常认为每个性能瓶颈都可以通过优化应用程序代码来解决,但并非总是如此。
有时候调整 HTTP 服务器的设置,使用更多资源或通过别的编程范式重新设计应用程序都是我们提升应用程序性能的解决方案。
在这种情况下, 构建系统 意味着理解我们应该灵活应用部署高性能应用程序的计算资源类型(进程,线程和“伪线程”)。
通过使用正确的理解,架构和实施正确的技术解决方案,我们可以避免陷入尝试通过优化应用程序代码来提高性能的陷阱。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 一行配置作业性能提升53%!Flink SQL 性能之旅
- Apache 性能配置优化
- MySQL性能参数配置总结
- PostgreSQL之性能优化中常用到的配置参数
- Zabbix 4.0性能调优配置详述
- [译]配置 sql.DB 获得更好的性能
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。