使用NGINX充分提升Python性能，第1部分：Web服务与缓存

NGINX | 2016年3月31日

Floyd Smith内容营销总监

简介：如何将NGINX与Python结合使用

Python以简单易用、富有趣味性而闻名，不仅能简化软件开发，据称其运行时性能也优于其他脚本语言。（不过，PHP的最新版本PHP 7可能会与Python一较高下。）

每个人都希望自己的网站和应用运行得更快。此外，流量持续增长或流量骤增的网站都容易出现性能问题和停机，而且往往发生在最糟糕的时候，也就是最繁忙的时段。事实上，无论流量是稳步增长还是使用量突然激增，几乎所有网站都会遇到性能问题和停机。

这正是NGINX和NGINX Plus的用武之地。它们通过以下三种方式提升网站性能：

作为Web服务器：NGINX最初是为了解决C10K问题，也就是轻松支持10,000个或更多并发连接。使用NGINX作为Python应用的Web服务器，即使流量较低，也能提升网站速度。当用户达到数千乃至更多时，几乎可以确定它能显著提升性能、减少崩溃并缩短停机时间。还可以在NGINX Web服务器上进行静态文件缓存或微缓存，但在单独的NGINX反向代理服务器上运行时，两者的效果会更好（请参阅下一段）。
作为反向代理服务器，您可以在当前应用服务器配置前直接部署NGINX作为反向代理服务器。NGINX面向Web接收请求，并将其转发至应用服务器。这个简单的方法可以加快网站运行速度、减少停机时间、降低服务器资源消耗并提升安全性。还可以在反向代理服务器上缓存静态文件（效率很高），并添加动态内容微缓存，以减轻应用本身的负载，还可实现更多功能。
用作多台应用服务器的负载均衡器：首先部署一台反向代理服务器。然后并行运行多台应用服务器，并使用NGINX或NGINX Plus对这些服务器之间的流量进行负载均衡，从而实现横向扩展。采用这种部署方式，可以根据流量需求轻松扩展网站性能，提高可靠性和正常运行时间。如果需要将特定用户会话保持在同一台服务器上，请配置负载均衡器以支持会话持久性。

无论将NGINX和NGINX Plus用作Python应用的Web服务器、反向代理服务器、负载均衡器，还是同时用于这三种用途，都能带来诸多优势。

在这个由两篇文章组成的系列中，本文是第一篇，将介绍提升Python应用性能的5个技巧，包括使用NGINX和NGINX Plus作为Web服务器，以及如何实现静态文件缓存和应用生成文件的微缓存。在第2部分中，我们将介绍如何使用NGINX和NGINX Plus作为反向代理服务器，以及如何为多台应用服务器提供负载均衡。

技巧 1：找出 Python 性能瓶颈

Python应用的性能在两种截然不同的情况下都很重要：一是日常用户数量处于“合理”范围时，二是承受高负载时。许多网站所有者对低负载下的性能重视不足。依我们之见，他们应该认真对待响应时间中每0.1秒的差异。将响应时间缩短几毫秒既困难又不易获得认可，但能提升用户满意度并改善业务成果。

不过，本篇博文及配套的第 2 部分将重点讨论大家普遍担心的情况：网站访问量增大时出现的性能问题，例如性能大幅下降和崩溃。此外，许多黑客攻击会产生类似于用户数量突然激增的影响，因此，提升网站性能通常也是应对攻击的重要一步。

对于像Apache HTTP Server这样为每位用户分配一定内存的系统，随着用户不断增加，物理内存会不堪重负。服务器开始使用磁盘交换空间，性能急剧下降，继而出现性能不佳和崩溃问题。按照本博文所述迁移到NGINX，有助于解决这一问题。

Python尤其容易出现与内存相关的性能问题，因为与其他脚本语言相比，它通常需要使用更多内存来完成任务（因此执行速度也更快）。所以，在其他条件相同的情况下，基于Python的应用可能会在用户负载较低时就“崩溃”，而使用其他语言编写的应用则不会。

优化应用可以在一定程度上有所帮助，但通常并不是解决流量相关网站性能问题的理想或快捷方式。本博文及配套的第 2 部分所介绍的步骤，可以更有效、更快速地解决此类性能问题。完成本文所述步骤后，可以再进一步改进应用，或重写应用以采用微服务架构。

技巧 2：选择单服务器或多服务器部署

小型网站部署在单台服务器上即可正常运行，而大型网站则需要多台服务器。但如果您的网站规模介于两者之间，或正从小型网站发展为大型网站，就需要考虑一些值得关注的部署方案。

如果采用单服务器部署，一旦流量激增或整体流量快速增长，就会面临重大风险。此类部署的可扩展性有限，可考虑改进应用、将Web服务器切换到NGINX、升级到容量更大且速度更快的服务器，或将存储卸载到内容分发网络（CDN）。这些方案都需要时间实施，会产生相应成本，并可能在实施过程中引入错误或其他问题。

此外，采用单服务器部署意味着您的网站存在单点故障风险，而许多可能导致网站离线的问题都无法快速或轻松解决。

NGINX与Python协同工作，利用NGINX的Web服务、负载均衡和缓存功能提升性能

在应用服务器“前端部署 NGINX”

在单服务器部署中，如果将服务器切换为NGINX，可以自由选择NGINX Open Source或NGINX Plus。NGINX Plus提供企业级支持和其他功能。其中一些功能（例如实时活动监控）适用于单服务器部署；另一些功能（例如负载均衡和会话持久性）则会在多服务器部署中使用NGINX Plus作为反向代理服务器时发挥作用。

综合考虑，除非您确信网站在未来很长一段时间内都会保持较小规模，并且不太担心停机，否则单服务器部署会存在一定风险。多服务器部署几乎可以按需扩展；通过合理设计可消除单点故障，并可根据需要调整性能，同时还能快速增加容量。

技巧 3：将Web服务器更换为NGINX

在Web发展初期，“Apache”几乎就是“Web服务器”的代名词。但NGINX于21世纪初开发，并日益普及；如今，它已是全球排名前首选Web服务器1,000、10,000、100,000以及[ngx_snippet name=’proportion-top-sites’]的网站中使用率领先的Web服务器。

NGINX旨在解决C10K问题，即在给定的内存预算内处理超过10,000个并发连接。其他Web服务器需要为每个连接分配一块内存，因此，当数千名用户同时访问一个网站时，物理内存会耗尽，导致服务器速度变慢或崩溃。NGINX单独处理每个请求，并可从容扩展以支持更多用户。（此外，它还非常适合其他用途，具体如下文所述。）

下面是NGINX架构的概览。

NGINX 架构，摘自《开源应用程序架构（第 II 卷）》

在图中，Python应用服务器对应后端的“应用服务器”模块，图中显示通过FastCGI访问该服务器。NGINX并不“知道”如何运行Python，因此需要通过网关连接到能够运行Python的环境。FastCGI是PHP、Python及其他语言广泛使用的接口。

不过，在Python与NGINX之间进行通信时，更常用的选择是Web服务器网关接口（WSGI）。WSGI可在多线程和多进程环境中运行，因此能够很好地扩展，适用于本博文提到的所有部署选项。

如果改用NGINX作为Web服务器，可以找到大量相关支持，帮助完成所需步骤：

配置gunicorn，即“Green Unicorn”，一种常用的WSGI服务器，可与NGINX配合使用。
配置uWSGI，另一款常用的WSGI服务器，可与NGINX配合使用。uWSGI直接支持NGINX。
使用uWSGI、NGINX和Django，一种广受欢迎的Python Web框架。

此代码片段展示了如何配置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服务器和应用服务器仍共享底层硬件。如果Web服务器占用硬件来检索缓存文件，即使检索效率很高，应用也无法使用这些硬件资源，因而可能会在一定程度上变慢。

要支持浏览器缓存，请为静态文件正确设置HTTP标头。请考虑HTTP Cache-Control 标头（尤其是其中的 max-age 设置）、Expires 标头和 Entity 标签。有关此主题的详细入门介绍，请参阅《NGINX Plus管理指南》中的“使用NGINX和NGINX Plus作为uWSGI和Django的应用程序网关”。

以下代码将NGINX配置为缓存静态文件，包括JPEG、GIF、PNG、MP4视频、PowerPoint等多种文件。请将www.example.com替换为Web服务器的URL。

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及其他语言的应用服务器性能的巨大潜力。按缓存方式划分，网页可分为三类：

静态文件：这些文件可以缓存，具体方法请参阅“技巧 4”。
应用生成的非个性化页面：通常不适合缓存此类页面，因为页面内容需要保持最新。例如，向未登录的电商用户提供的页面（见下一点）中，可购买的商品、推荐的类似商品等内容可能不断变化，因此提供最新页面非常重要。不过，如果另一位用户在很短的时间后（例如0.1秒后）访问，向其显示与上一位用户相同的页面也可能完全可行。
应用生成的个性化页面：这类页面针对特定用户，且同一用户不太可能两次看到相同的个性化页面，因此缓存并无实际意义。例如，为已登录用户生成的电子商务页面不能向其他用户显示。

静态文件和由应用程序生成的非个性化文件可以缓存

微缓存适用于上述第二类页面，即由应用生成的非个性化页面。“微”是指时间很短。如果网站每秒多次生成同一页面，将其缓存1秒可能不会对页面的新鲜度造成太大影响。但如此短暂的缓存也能大幅减轻应用服务器的负载，尤其是在流量激增期间。在缓存超时期限内，应用无需生成10个、20个或100个内容相同的页面，只需生成一次指定页面，随后将其缓存，并从缓存中提供给众多用户。

效果堪称显著。原本每秒处理数十个请求时速度缓慢的服务器，在每秒只需处理一个请求时会变得相当迅速。（当然，此外还需处理个性化页面。）F5的Owen Garrett在一篇博客文章中详细介绍了微缓存的优势，并提供了配置代码。核心改动是设置超时时间为1秒的代理缓存，只需几行配置代码即可完成。

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

如需更多配置示例，请参阅Tyler Hicks‑Wright撰写的博客文章《结合NGINX使用Python和uWSGI》。