摘要：無論是將其用作的服務器反向代理服務器負載均衡器，還是同時使用以上三種功能，和都能帶來很大好處。再就是下篇文章會介紹如何把和當作反向代理服務器和多個應用程序服務器的負載均衡器。而使用將會有助于解決這一問題。

【編者按】本文主要介紹 nginx 的主要功能以及如何通過 NGINX 優化 Python 應用性能。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。

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 當作反向代理服務器和多個應用程序服務器的負載均衡器。

檢驗 Python 應用程序的性能分有兩種不同情況。

第一種是在日常合理用戶數量的情況下；第二種則是負載很大的情況下。

很多站長毫不關心輕負載時網站性能，然而殘酷的現實經驗告訴我們，響應時間的每一秒鐘都應該為之捏一把汗。雖然將響應時間縮短幾毫秒是個苦差事，但卻會帶來更好的用戶體驗和更好的運營成果。

另一個就是所有人都擔心的情境：網站繁忙時出現的性能問題，例如運行嚴重減緩和崩潰。此外，很多黑客攻擊也會表現為用戶數量急劇增長，所以改善網站性能也是解決攻擊問題的重要一步。

服務器會為每位用戶分配一定數量的內存，例如 Apache HTTP 服務器，隨著用戶數量的增長，物理內存就會出現超負載，服務器開始將數據交換到磁盤上，性能驟降，隨之產生性能不良和崩潰。而使用 NGINX 將會有助于解決這一問題。

Python 尤其容易發生內存相關的性能問題，因為它在執行任務時一般比其它腳本語言占用更多的內存（因此它的執行速度更高）。因此，在同等條件下，基于 Python 的應用程序可能比其他語言的應用程序能承受的用戶負載量更小。

優化應用程序或多或少會有幫助，但是這通常不是流量相關網站性能問題的最佳或最快解決方案。本文后續會列出解決流量相關問題的最佳/最快解決方案。當你看完本文后，無論如何都要回去優化你的應用程序，或者使用微服務架構重寫。

小網站只要配置單一服務器就可以運行良好，大網站則需要有多個服務器。而如果你處于中間地帶，或者你的網站正在由小網站發展壯大起來，那你就要做些有意思的選擇了。

如果你只具配置有單一服務器的能力，那么在流量峰值或整體流量迅速增長時，你會面臨極大風險。因為此時你的擴展性會受限，此時解決問題的方法可以包括優化應用程序、把網絡服務器改成 NGINX、換一個更大更快的服務器，或者把存儲任務轉移到內容分發網絡（CDN）等。這其中每一個選項都需要耗費時間、成本，并且在實施過程中都可能會引入錯誤和問題。

此外，配置單一服務器的情況下，你的網站就有一個單一的失敗節點，會有很多問題造成你的網站下線而且沒有很快很簡捷的解決方法。

如果把配置單一服務器改成使用 NGINX，可以自由選擇開源 NGINX 軟件或 NGINX Plus。NGINX Plus 包含企業級支持及額外功能。有些額外功能可以在單一服務器配置狀況下實現，例如實時活動監控，而有些功能只有在把 NGINX Plus 作為多個服務器配置下的反向代理服務器時才會出現，例如負載均衡和會話持久性。

綜合以上所有考慮，除非你確信你的網站在接下來很長時間都不會擴大規模，停止運行也不會有大麻煩，可以抵抗一些其他的風險，那可以配置單一服務器。但別忘了配置多個服務器幾乎可以隨意擴展---單次失敗完全可以處理，能迅速擴充容量，總之你應用的性能由你來定。
Tip 3 – Change Your Web Server to NGINX

在網絡發展早期，Apache等同于web 服務器。但是21世紀初 NGINX 誕生之后使用越來越廣泛，它已經成為世界上流量前1000、10000和100000的公司的 web 服務器首選。

NGINX 的設計初衷是解決 C10K 問題，也就是在給定內存預算的范圍內能支持10000以上的同時訪問。其它 web 服務器需要給每個訪問分配一部分內存，但當幾千名用戶同時訪問網站時，它們會面臨物理內存不足、運行緩慢或崩潰的問題。NGINX 分別處理每個請求，并且能優雅地應對更多用戶。（如上文所述，它在其它功能方面也有優異表現。）

以下為 NGINX 架構的概述。

在本圖中，是一個 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;
        }
    }
}

靜態數據緩存包括把那些不經常變更的文件（也許是幾個小時，也許是永遠不變）存在一個應用程序服務器之外的地方。靜態文件的典型例子就是作為網頁內容一部分展示的 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;
    }
}

微程序緩存給了那些運行 Python、PHP 和其它語言的應用程序服務器提升性能的大好機會。可緩存的網頁有以下3種類型：

靜態文件---可緩存，見技巧4。

應用程序生成的、非個人化頁面---一般來說，緩存這些沒有意義，因為這些內容需要不斷更新。舉個例子，用戶登錄電商網站時看到的頁面（見下段）---在售商品、同類商品推薦等等可能會不斷更新，因此提供最新的網頁非常重要。不過，如果另一個用戶在十分之一秒之后登錄，向他們展示前一位用戶看到的同樣頁面也沒有什么問題。

應用程序生成的、個人化頁面---這些通常不會被緩存，因為它們是單個用戶所屬，而且同一個用戶也不會再次看到相同的頁面。舉個例子，用戶登錄電商網站后看到的頁面，同樣的頁面不能向其他用戶展示。

微程序緩存對上述第二種網頁類型很有用---應用程序生成的、非個人化頁面。微是一個概括的時間范圍。如果你的網站一秒之內數次生成同樣的頁面，緩存一秒鐘就不會影響網頁的新鮮度。不過這個概括的緩存時間期限會極大地減輕應用程序服務器的負擔，尤其是流程峰值期間。在緩存逾時期限內，不用生成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.。

在這部分，本文介紹了提升單一服務器提升 Python 應用性能的解決方案，可以在單一服務器上配置，也可在反向代理服務器或多帶帶的緩存服務器上實現。（緩存在多帶帶的服務器上運行更好。）接下來的第二部分介紹需要兩個或更多服務器才能實現的性能提升方案。

當然如果你想了解 NGINX Plus 適用于你的應用程序的高級功能，例如支持、實時活動監控、運行時同時配置，可以去 NGINX 官網查看。

OneAPM 能夠幫你查看 Python 應用程序的方方面面，不僅能夠監控終端的用戶體驗，還能監控服務器性能，同時還支持追蹤數據庫、第三方 API 和 Web 服務器的各種問題。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：Maximizing Python Performance with NGINX, Part I: Web Serving and Caching