Nginx 性能調優
原文地址：http://nginx.com/blog/tuning-nginx/
Tuning NGINX for Performance
Nginx 性能調優
NGINX is well known as a high performance load balancer, cache and web server, powering over 40% of the busiest websites in the world. Most of the default NGINX and Linux settings work well for most use cases, but it can be necessary to do some tuning to achieve optimal performance. This blog post will discuss some of the NGINX and Linux settings to consider when tuning a system. There are many settings available, but for this post we will cover the few settings recommended for most users to consider adjusting. The settings not covered in this post are ones that should only be considered by those with a deep understanding of NGINX and Linux, or after a recommendation by the NGINX support or professional services teams. NGINX professional services has worked with some of the world’s busiest websites to tune NGINX to get the maximum level of performance and are available to work with any customer who needs to get the most out of their system.
Nginx聞名于高性能負載均衡，緩存和web服務器，為全世界40%最繁忙的網站提供支持。在我們大多數使用情況下，默認的 Nginx 和 Linux 配置能得到滿足。但是有時候調試出更優的性能是很有必要的。本文將討論調試一個系統時需要考慮的Nginx 和 Linux 設置。有很多的設置可用，但是本博中我們只涉及到少數幾個大多數用戶調試時推薦過的設置項。本文沒有提及的配置項通常是那些對Nginx 和 Linux 有著深入理解的用戶會使用到，或者是在 Nginx 官方或專業服務團隊推薦才會使用。Nginx 專業服務幫助那些世界上訪問量最大的網站調試 Nginx 以達到最高性能，還有那些需要想要充分利用他們系統的顧客。
Introduction
簡介
A basic understanding of the NGINX architecture and configuration concepts is assumed. This post will not attempt to duplicate the NGINX documentation, but will provide an overview of the various options with links to the relevant documentation.
本文假設讀者已經對Nginx的架構和配置的概念有了基本的理解，因此不是去簡單的復制一份 Nginx 文檔，但是會提供各種選項的概述以及相關文檔的鏈接。
A good rule to follow when doing tuning is to change one setting at a time and if it does not result in a positive change in performance, then to set it back to the default value.
一個很好的原則是調優時每次只修改一個配置，如果對配置的修改不能提高性能的話，改回默認值。
We will start with a discussion of Linux tuning since some of these values can impact some of the values you will use for your NGINX configuration.
我們將從Linux調優開始因為有些值會影響到你調優Nginx時用到的一些配置參數。
Linux Configuration
Linux 配置
Modern Linux kernels (2.6+) do a good job in sizing the various settings but there are some settings that you may want to change. If the operation system settings are too low then you will see errors in the kernel log to help indicate that you should adjust them. There are many possible Linux settings but we will cover those settings that are most likely in need of tuning for normal workloads. Please refer to Linux documentation for details on adjusting these settings.
流行的 Linux 內核（2.6以后）在各種設置的大小調整上做得很好了但是同樣有一些設置是你可能想要修改的。如果你的操作系統設置太低導致你在內核日志里看到錯誤信息了，那表明你應該調整配置了。可能的Linux 配置有很多但是我們只討論幾個在普通工作負載調優下需要用到的。請參考 Linux 文檔獲取這些調整到的配置項的詳情。
The Backlog Queue
積壓隊列
The following settings relate directly to connections and how they are queued. If you have high rate of incoming connections and you are setting uneven levels of performance, for example some connections appear to be stalling, then running these settings may help.
下面這些配置直接與連接和連接如何排隊相關。如果你高速率的接入并且你的性能配置不均衡，例如一些連接出現延時的情況，那么下面的調優配置將起到作用。
net.core.somaxconn: This sets the size of the queue for connections waiting for NGINX to accept them. Since NGINX accepts connections very quickly, this value does not usually need to be very large, but the default can be very low, so increasing can be a good idea if you have a high traffic website. If the setting is too low then you should see error message in the kernel log and increase this value until the errors stop. Note: if you set this to a value greater then 512, you should change your NGINX configuration using the backlog parameter of the listen directive to match this number.
net.core.somaxconn：這一項設置了等待 Nginx 接收的連接隊列的大小。因為 Nginx 接受連接非常快，所以這個值一般不需要太大，但是默認值很低，所以如果你的網站流量很高的話把這個值加大是很好的辦法。如果這個值過低，你會在內核日志里看到錯誤信息，那就要一直增大這個值直到不再報錯。注意：如果你設置此值大于512，你需要把Nginx 配置中的 listen 指令的 backlog 參數修改與此數相等。(譯者注：listen 指令的 backlog 這個參數設置了等待邊接的隊列的最大長度。默認情況下，backlog 在FreeDSB 和 Mac OS X 下設置為 -1，其他平臺為511)
net.core.netdev_max_backlog: This sets the rate at which packets can be buffered by the network card before being handed off the the CPU. For machines with a high amount of bandwidth this value may need to increased. Check the documentation for your network card for advice on this setting or check the kernel log for errors relating to this setting.
net.core.netdev_max_backlog：這一項設置包在哪個速率下會被網卡在移交CPU之前緩沖。 當主機需要非常大的流量的時候這個值需要增加。查看一下你的網卡的文檔對這個設置的建議，或者看看內核日志中與該項曙光的錯誤。
File Descriptors
文件描述符
File descriptors are operating system resources used to handle things such as connections and open files. NGINX can use up to two file descriptors per connection, for example if it is proxying, then it can have one for the client connection and another for the connection to the proxied server, although if HTTP keepalives are used this ratio will be much lower. For a system that will see a large number of connections, these settings may need to be adjusted:
文件描述符是用來處理如連接或者打開的文件等的操作系統資源。Nginx 每個連接可以建立兩個描述符，例如它在進行代理 ，那么它有一個指向客戶端連接，一個指向代理服務器連接，盡管在使用 HTTP 長連接的情況下這個比率很低。
sys.fs.file_max: This is the system wide limit for file descriptors.
sys.fs.file_max：這一項是文件描述符的系統范圍限制。
nofile: This is the user file descriptor limit and is set in the /etc/security/limits.conf file.
nofile是用戶文件描述符的限制，在/etc/security/limits.conf文件中設置。
Ephemeral ports
臨時端口
When NGINX is acting as a proxy, each connection to an upstream server uses a temporary, or ephemeral port.
當Nginx作為一個代理時，每一個到上游服務器的連接都使用臨時端口。
net.ipv4.ip_local_port_range: This specifies the starting and ending port value to use. If you see that you are running out of ports, you can increase this range. A common setting it use ports 1024 to 65000.
net.ipv4.ip_local_port_range：這一項指定了可用端口的范圍。如果你發現你運行在這些端口以外，那么你需要增大這個范圍了。通常的設置范圍為1024 到 65000。
net.ipv4.tcp_fin_timeout: This specifies how long after port is no being used that it can be used again for another connection. This usually defaults to 60 seconds but can usually be safely reduced to 30 or even 15 seconds.
net.ipv4.tcp_fin_timeout：這一項指定一個端口多久沒有被使用之后可以被其他連接使用。通常默認的默認為60秒，不過減到30秒甚至15秒會更安全。
NGINX Configuration
Nginx 配置
The following are some NGINX directives that can impact performance. As stated above, we will only be discussing those directives that we recommend most users look at adjusting. Any directive not mentioned here is one that we recommend not to be changed without direction from the Nginx team.
接下來是一些會影響性能的 Nginx 指令。如上所述，我們只討論大多數用戶調試時推薦的指令。本文沒有提到的指令，我們建議在沒有Nginx 團隊的指導下不要隨便改動。
Worker Processes
工作進程
NGINX can run multiple worker processes, each capable of processing a large number of connections. You can control how many worker processes are run and how connections are handled with the following directives:
Nginx能運行多個工作進程，每一個工作進程能處理很大量的連接。你可以通過下面的指令集控制運行多少個工作進程，以及如果處理連接：
worker_processes: This controls the number of worker processes that NGINX will run. In most cases, running one worker process per CPU core works well. This can be achieved by setting this directive to “auto”. There are times when you may want to increase this number, such as when the work processes have to do a lot of disk I/O. The default is 1.
worker processes：這一項是Nginx運行的工作進程。在多數情況下，有幾個CPU內核就運行幾個工作進程。這個值也可以通過將該指令設置為 ”auto” 取得。也有些時間你需要調大這個數，比如當工作進程需要從大量磁盤讀寫的時候。該值默認為1.
worker_connections: This is the maximum number of connections that can be processed at one time by each worker process. The default is 512, but most systems can handle a larger number. What this number should be set to will depend on the size of the server and the nature of the traffic and can be discovered through testing.
worker_connections：這是一個工作進程可以同時處理的最大連接數。默認為512，但是多數系統可以處理更大的數。這一項的取值取決于服務器和大小和流量的性質，這些都可以通過測試得到。
Keepalives
Keepalives
Keepalive connections can have a major impact on performance by reducing the CPU and network overhead needed for opening and closing connections. NGINX terminates all client connections and has separate and independent connections to the upstream servers. NGINX supports keepalives for the client and upstream servers. The following directives deal with client keepalives:
Keepalive 連接可以通過降低CPU和網絡在打開和關閉連接時需要的開銷來影響性能。Nginx終止了所有客戶端請求并且分離和獨立了所有連接上游服務器的連接。Nginx支持客戶端和上游服務器的長連接。接下來這些指令處理客戶端 keepalives：
keepalive_requests: This is the number of requests a client can make over a single keepalive connection. The default is 100, but can be set to a much higher value and this can be especially useful for testing where the load generating tool is sending many requests from a single client.
keepalive_requests：這是一個客戶端可以通過一個keepalive連接的請求次數。缺省值是100，但是也可以調得很高，而且這對于測試負載生成工具從哪里使用一個客戶端發送這么多請求非常有用。
keepalive_timeout: How long a keepalive connection will remain open once it becomes idle.
The following directives deal with upstream keepalives:
keepalive_tiimeout：一個keepalive 連接被閑置以后還能保持多久打開狀態。
下面這些指令處理upstream keepalives：
keepalive: This specifies the number of idle keepalive connections to an upstream server that remain open for each worker process. There is no default value for this directive.
keepalive：這一項指定一個工作進程保持打開狀態的閑置的上游服務器的連接數。這一項沒有缺省值。
To enable keepalive connections to the upstream you must add the following directives:
proxy_http_version 1.1;
proxy_set_header Connection “”;
要啟用upstream的keepalive 連接，你必須加入下面的指令：
proxy_http_version 1.1;
proxy_set_header Connection “”;
Access Logging
訪問日志記錄
Logging each requests takes both CPU and I/O cycles and one way to reduce this impact is to enable access log buffering. This will cause NGINX to buffer a series of log entries and write them to the file at one time rather then as separate write operation. Access log buffering is enabled by specifying the “buffer=size” option of the access_log directive. This sets the size of the buffer to be used. You can also use the “flush=time” option to tell NGINX to write the entries in the buffer after this amount of time. With these two options defined, NGINX will write entries to the log file when the next log entry will not fit into the buffer or if the entries in the buffer are older than the time specified for the flush parameter. Log entries will also be written when a worker process is re-opening log files or is shutting down. It is also possible to disable access logging completely.
記錄每一個請求同時需要CPU和I/O周期，減少這一影響的一個方法就是啟用訪問日志緩存。打開后能使Nginx一次性緩沖一堆日志內容到文件里而不每一條日志做一次寫操作。訪問日志的緩沖是通過設置 access_log 指的 “buffer=size” 選項來啟用的。這一項設置緩沖區的大小。也可以通過 “flush=time” 一項設置 Nginx 將緩沖區中所有數據寫到文件的間隔時間。這兩項都定義了以后，Nginx將在緩沖區滿了或者緩沖區里的條目生成時間比 flush 參數指定的時間更早的情況下把緩沖區里的全部條目寫入日志文件。日志記錄還會在工作進程重新打開或者關閉日志文件時寫入。這也可能徹底地彬訪問日志。
Sendfile
Sendfile is an operating system feature that can be enabled on NGINX. It can provide for faster tcp data transfers by doing in-kernel copying of data from one file descriptor to another, often achieving zero-copy. NGINX can use it to write cached or on-disk content down a socket, without any context switching to user space, making it extremely fast and using less CPU overhead. Because the data never touches user space, it’s not possible to insert filters that need to access the data into the processing chain, so you cannot use any of the NGINX filters that change the content, e.g. the gzip filter. It is disabled by default.
Sendfile 是Nginx可以啟用的一個操作系統功能。它能通過在內核中從一個文件描述符拷貝數據到另一個文件描述符來提供更快的 tcp 數據傳輸，通常能實現零拷貝。Nginx 能使用這個功能在沒有任何上下文切換到用戶空間的情況下，通過套接字寫緩存或者磁盤里的內容，能免速度極快且使用更少的CPU開銷。因為數據進不了用戶空間，所以也不可能插入進程鏈中需要到的過濾器，所以你不能夠使用任何的Nginx過濾器來修改這些內容，例如gzip過濾器，默認是禁用的。
Limits
NGINX and NGINX Plus allow you to set various limits that can be used to help control the resources consumed by clients and therefore impact the performance of your system and also affect user experience and security. The following are some of these directives:
Nginx 和 Nginx 加可以設置各種限制來幫助控制來自客戶端的資源消耗，提升系統性能，提升用戶體驗和安全性。下面就是些想著的指令：
limit_conn/limit_conn_zone: These directives can be used to limit the number of connections NGINX will allow, for example from a single client IP address. This can help prevent individual clients from opening too many connections and consuming too many resources.
linut_conn/limit_conn_zone：這兩個指令用于限制Nginx允許的連接數量，例如從一個IP地址來的連接數量。能夠幫助阻止個別的客戶端利用打開許多的連接來消耗過多的資源。
limit_rate: This will limit the amount of bandwidth allowed for a client on a single connection. This can prevent the system from being overloaded by certain clients and can help to ensure that all clients receive good quality of service.
limit_rate：限制單個連接的帶寬量。能夠防止系統因一些客戶端而超載，能確保所有用戶都享用質量的服務。
limit_req/limit_req_zone: These directives can be used to limit the rate of requests being processed by NGINX. As with limit_rate this can help prevent the system from being overloaded by certain clients and can help to ensure that all clients receive good quality of service. They can also be used to improve security, especially for login pages, by limiting the requests rate so that it is adequate for a human user but one that will slow programs trying to access your application.
limit_req/limit_req_zone：這些指令用于限制正在被Nginx 處理的請求的比率。使用 limit_rate 能防止系統某幾個客戶端超載并且能確保所有客戶獲取高質量的服務。這些指令同樣能提高安全性，尤其是登錄頁，通過限制請求率來做更適合人類用戶的請求，減慢試圖訪問你應用的程序用戶。
max_conns: This is set for a server in an upstream group and is the maximum number of simultaneous connections allowed to that server. This can help prevent the upstream servers from being overloaded. The default is zero, meaning that there is no limit.
max_conns：該項設置上游分組里的服務器允許同時連接的最大數目。能限制上游服務器的的超載。缺省值為0，即無限制。
queue: If max_conns is set for any upstream servers, then the queue directive governs what happens when a request cannot be processed because there are no available servers in the upstream group and some of those servers have reached the max_conns limit. This directive can be set to the number of requests to queue and for how long. If this directive is not set, then no queueing will occur.
queue：如果有上游服務器配置的max_conns一項，當有請求因為沒有可用的上游分組中的服務器并且有些服務器達到max_conns的限制時，queue指令便起使用。queue 指令能決定請求隊列的大小和時長。如果該值沒有配置，那么不會有隊列產生。
Additional considerations
其他注意事項
There are additional features of NGINX that can be used to increase the performance of a web application that don’t really fall under the heading of tuning but are worth mentioning because their impact can be considerable. We will discuss two of these features.
還有一些不是非要放到調優這個標題下的Nginx功能能夠提高一個網站應用的性能，但是依然要提一下因為他們的影響是值得注意的。我們討論這其中的兩個功能。
Caching
緩存
By enabling caching on an NGINX instance that is load balancing a set of web or application servers, you can dramatically increase the response time to the client while at the same time dramatically reducing the load on the backend servers. Caching is a subject of its own and will not be covered here. For more information on configurating NGINX for caching please see: NGINX Admin Guide – Caching.
在一組做了負載均衡的網站或應用服務器上開啟緩存 ，能夠戲劇性地在減輕后端服務器負載的同時增加（譯者注：怎么覺得應該是優化或者減少的意思，作者寫錯了？）到客戶端的響應時間。緩存是Nginx 自己的主題在這時太不多言。更多信息情看：NGINX 管理指南——緩存。
Compression
壓縮
Compressing the responses to clients can greatly reduce the size of the responses, requiring less bandwidth, however it does require CPU resources to do the compression so is best used when there is value to reducing bandwidth. It is important to note that you should not enable compression for objects that are already compressed, such as jpegs. For more information on configuring NGINX for compression please see: NGINX Admin Guide – Compression and Decompression
壓縮到客戶端的響應能夠很顯著的減少響應大小，減少所需帶寬，然后需要耗費CPU資源來進行壓縮所以最后是在減少帶寬 有價值的時候再使用。特別注意的是如果你的對象已經壓縮過了如jpegs，那就不需要再啟用壓縮了。更多關于配置Nginx壓縮的信息請看： NGINX 管理指南——壓縮與解壓縮。
來自：http://blog.csdn.net/agangdi/article/details/40838499