转载

利用 NGINX 最大化 Python 性能，第一部分：Web 服务和缓存

简介---如何在Python 中使用 NGINX

Python 的著名之处在于使用简单方便，软件开发简单，而且据说运行性能优于其它脚本语言。（虽然最新版本的 PHP、PHP 7 可能会与它展开激烈竞争。）

所有人都希望自己的网站和应用程序运行得更快一些。但是，每个网站在流量增长或骤然出现流量峰值时都很容易发生性能问题、甚至宕机（这一般会在服务器最繁忙的时候发生）。此外在运行期间，无论是流量稳步增长还是使用量急速飞涨，几乎所有的网站都会经历性能问题。

而关于网站性能问题，那就到了 NGINX 和 NGINX Plus 发挥作用的时候。一般可以通过以下三种方式改善网站性能：

作 web 服务器，NGINX 最开始的设计初衷就是解决 C10K 问题，也就是能够轻松支持1万以上的同时访问。NGINX 作为 Python web 服务器，可以保证网站在流量较低时依然能够快速运行。当拥有上千名用户同时访问时，你就必须提供更高性能、更少崩溃和更短停机时间的 web 服务器。你也可以在 NGINX 服务器上进行静态文件缓存或微程序缓存，不过这两者在单独的 NGINX 反向代理服务器（见下段）上运行表现更佳。

做反向代理服务器---你可以在当前应用程序服务器上把 NGINX 设置为反向代理服务器。NGINX 会将网络请求发送到应用程序服务器。这种古怪招数可以提高网站运行速度，减少停机时间，减少服务器资源占用，并且提高网站安全。你还可以在反向代理服务器上缓存静态数据（非常高效），增加动态数据的微程序缓存，从而减少应用程序本身的负担。

做多个应用程序服务器的负载均衡器---首先要部署反向代理服务器，然后同时运行多个应用程序服务器，并使用 NGINX 或 NGINX Plus 来均衡经过它们传送的流量，进行扩展。通过这种部署，你可以轻松的根据流量需求来衡量网站性能，增加可靠度和正常运行时间。如果你需要既定的用户会话保存在同一个服务器上，配置负载均衡器还可以支持会话持久性。

无论是将其用作 Python 的 web 服务器、反向代理服务器、负载均衡器，还是同时使用以上三种功能，NGINX 和 NGINX Plus 都能带来很大好处。

下面介绍改善 Python 应用程序性能的5个技巧，本文会分多个章节进行介绍，包括把 NGINX 和 NGINX Plus 作为 web 服务器，如何实施静态文件缓存，以及微程序缓存应用程序生成文件。

再就是下篇文章会介绍如何把 NGINX 和 NGINX Plus 当作反向代理服务器和多个应用程序服务器的负载均衡器。

技巧1---找出 Python 性能瓶颈

检验 Python 应用程序的性能分有两种不同情况。

第一种是在日常合理用户数量的情况下；第二种则是负载很大的情况下。

很多站长毫不关心轻负载时网站性能，然而残酷的现实经验告诉我们，响应时间的每一秒钟都应该为之捏一把汗。虽然将响应时间缩短几毫秒是个苦差事，但却会带来更好的用户体验和更好的运营成果。

另一个就是所有人都担心的情境：网站繁忙时出现的性能问题，例如运行严重减缓和崩溃。此外，很多黑客攻击也会表现为用户数量急剧增长，所以改善网站性能也是解决攻击问题的重要一步。

服务器会为每位用户分配一定数量的内存，例如 Apache HTTP 服务器，随着用户数量的增长，物理内存就会出现超负载，服务器开始将数据交换到磁盘上，性能骤降，随之产生性能不良和崩溃。而使用 NGINX 将会有助于解决这一问题。

Python 尤其容易发生内存相关的性能问题，因为它在执行任务时一般比其它脚本语言占用更多的内存（因此它的执行速度更高）。因此，在同等条件下，基于 Python 的应用程序可能比其他语言的应用程序能承受的用户负载量更小。

优化应用程序或多或少会有帮助，但是这通常不是流量相关网站性能问题的最佳或最快解决方案。本文后续会列出解决流量相关问题的最佳/最快解决方案。当你看完本文后，无论如何都要回去优化你的应用程序，或者使用微服务架构重写。

技巧2---选择单一服务器或多个服务器配置

小网站只要配置单一服务器就可以运行良好，大网站则需要有多个服务器。而如果你处于中间地带，或者你的网站正在由小网站发展壮大起来，那你就要做些有意思的选择了。

如果你只具配置有单一服务器的能力，那么在流量峰值或整体流量迅速增长时，你会面临极大风险。因为此时你的扩展性会受限，此时解决问题的方法可以包括优化应用程序、把网络服务器改成 NGINX、换一个更大更快的服务器，或者把存储任务转移到内容分发网络（CDN）等。这其中每一个选项都需要耗费时间、成本，并且在实施过程中都可能会引入错误和问题。

此外，配置单一服务器的情况下，你的网站就有一个单一的失败节点，会有很多问题造成你的网站下线而且没有很快很简捷的解决方法。

利用 NGINX 最大化 Python 性能，第一部分：Web 服务和缓存

如果把配置单一服务器改成使用 NGINX，可以自由选择开源 NGINX 软件或 NGINX Plus。NGINX Plus 包含企业级支持及额外功能。有些额外功能可以在单一服务器配置状况下实现，例如实时活动监控，而有些功能只有在把 NGINX Plus 作为多个服务器配置下的反向代理服务器时才会出现，例如负载均衡和会话持久性。

综合以上所有考虑，除非你确信你的网站在接下来很长时间都不会扩大规模，停止运行也不会有大麻烦，可以抵抗一些其他的风险，那可以配置单一服务器。但别忘了配置多个服务器几乎可以随意扩展---单次失败完全可以处理，能迅速扩充容量，总之你应用的性能由你来定。Tip 3 – Change Your Web Server to NGINX

技巧3---把你的 web 服务器改成 NGINX

在网络发展早期， Apache 等同于 web 服务器。但是21世纪初 NGINX 诞生之后使用越来越广泛，它已经成为世界上流量前1000、10000和100000的公司的 web 服务器首选。

NGINX 的设计初衷是解决 C10K 问题，也就是在给定内存预算的范围内能支持10000以上的同时访问。其它 web 服务器需要给每个访问分配一部分内存，但当几千名用户同时访问网站时，它们会面临物理内存不足、运行缓慢或崩溃的问题。NGINX 分别处理每个请求，并且能优雅地应对更多用户。（如上文所述，它在其它功能方面也有优异表现。）

以下为 NGINX 架构的概述。

利用 NGINX 最大化 Python 性能，第一部分：Web 服务和缓存

在本图中，是一个 Python 应用程序服务器的后台应用程序块，需要通过 FastCGI 来访问。NGINX 并不知道如何运行 Python，因此它需要关口来进入一个能够运行 Python 的环境。FastCGI 是 PHP、Python 等语言广泛使用的用户界面。

不过，Python 和 NGINX 之间的沟通更常用的备选是服务网关接口（WSGI）。WSGI 可以在多线程、多进程环境下运行，因此它可以在本文提到的所有配置选择下运行。

如果你要把 NGINX 作成你的 web 服务器，网上有很多操作帮助信息：

配置 gunicorn--- 绿色独角兽，一个很有名的 WSGI 服务器，以便使用 NGINX。
配置 uWSGI---另外一个有名的 WSGI 服务器，以便使用 NGINX。uWSGI 能够直接支持 NGINX.
使用 uWSGI、NGINX 和Django---一个很常用的 Python 网站框架。

以下片段展示了如何配置 NGINX 来与 uWSGI 一起运行（给出的实例是使用 Python 框架 Django 的一个项目）：

http {     ...     upstream django {        server 127.0.0.1:29000;     }      server {         listen 80;         server_name myapp.example.com;          root /var/www/myapp/html;          location / {             index index.html;         }          location /static/  {             alias /var/django/projects/myapp/static/;         }          location /main {             include /etc/nginx/uwsgi_params;             uwsgi_pass django;              uwsgi_param Host $host;             uwsgi_param X-Real-IP $remote_addr;             uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;             uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;         }     } }

技巧4——实施静态数据缓存

静态数据缓存包括把那些不经常变更的文件（也许是几个小时，也许是永远不变）存在一个应用程序服务器之外的地方。静态文件的典型例子就是作为网页内容一部分展示的 JPEG 图像。

静态文件缓存是增强应用程序性能的常见方法，而且实际上会在下面几个层面发生：

在用户的浏览器
多个层级的网络提供者---从一家公司的内网，到互联网服务供应商(ISP)
web 服务器上，正如本文所述

在 web 服务器上实施静态数据缓存有两个好处：

更快传送到用户---NGINX 针对静态数据缓存做了优化，执行静态内容的请求的速度比应用程序服务器快得多。
减轻应用服务器的负担---应用服务器甚至不会收到缓存静态数据的请求，因为网络服务器已经实现这些请求。

静态文件缓存在单个服务器执行时运行良好，但其实硬件方面依然由 web 服务器和应用程序服务器共享。如果 web 服务器使用硬件找回缓存的文件（及时非常高效）应用程序将无法使用这些硬件，运行速度可能会受到影响。

要支持浏览器缓存，就要为静态文件正确设置 HTTP 标头。需要考虑 HTTP 缓存控制标头（尤其是它的 max‑age 设置）、Expires 标头和实体标签。如想了解更多这方面的介绍，可以参考 Using NGINX as an Application Gateway with uWSGI and Django 。

下面的代码配置 NGINX，用于缓存包括 JPEG 文件、GIF、PNG文件、MP4 视频文件、ppt等多种类型的静态文件（用你的网址来替代 www.example.com ）：

server {     # substitute your web server's URL for "www.example.com"     server_name www.example.com;     root /var/www/example.com/htdocs;     index index.php;     access_log /var/log/nginx/example.com.access.log;     error_log /var/log/nginx/example.com.error.log;     location / {         try_files $uri $uri/ /index.php?$args;     }     location ~ /.php$ {         try_files $uri =404;         include fastcgi_params;         # substitute the socket, or address and port, of your Python server         fastcgi_pass unix:/var/run/php5-fpm.sock;         #fastcgi_pass 127.0.0.1:9000;     }       location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg                   |jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid                   |midi|wav|bmp|rtf)$ {         expires max;         log_not_found off;         access_log off;     } }

技巧5---实施微程序缓存

微程序缓存给了那些运行 Python、PHP 和其它语言的应用程序服务器提升性能的大好机会。可缓存的网页有以下3种类型：

静态文件---可缓存，见技巧4。
应用程序生成的、非个人化页面---一般来说，缓存这些没有意义，因为这些内容需要不断更新。举个例子，用户登录电商网站时看到的页面（见下段）---在售商品、同类商品推荐等等可能会不断更新，因此提供最新的网页非常重要。不过，如果另一个用户在十分之一秒之后登录，向他们展示前一位用户看到的同样页面也没有什么问题。
应用程序生成的、个人化页面---这些通常不会被缓存，因为它们是单个用户所属，而且同一个用户也不会再次看到相同的页面。举个例子，用户登录电商网站后看到的页面，同样的页面不能向其他用户展示。

利用 NGINX 最大化 Python 性能，第一部分：Web 服务和缓存

微程序缓存对上述第二种网页类型很有用---应用程序生成的、非个人化页面。微是一个概括的时间范围。如果你的网站一秒之内数次生成同样的页面，缓存一秒钟就不会影响网页的新鲜度。不过这个概括的缓存时间期限会极大地减轻应用程序服务器的负担，尤其是流程峰值期间。在缓存逾时期限内，不用生成10次、20次、100次（相同的内容），而是生成既定的网页一次，然后这个网页就会被缓存，并且通过缓存向多个用户展示。

而这产生的效果却不可思议，服务器一秒钟处理大量请求运行缓慢，但在只处理一个请求时速度是极快的。（当然，还有任何个人化的页面）。设置一秒超时的代理服务器这样的核心变化只需要几行配置代码。

proxy_cache_path /tmp/cache keys_zon/=cache:10m levels=1:2 inactive=600s max_size=100m; server {     proxy_cache cache;     proxy_cache_valid 200 1s;     ... }

更多配置范例，请参考 Tyler Hicks‑Wright 的博客 Python and uWSGI with NGINX. 。