Nginx的uwsgi模块常用参数说明
官方文档地址：http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html
ngx_http_uwsgi_module模块允许把请求传递给uwsgi服务器。
配置示例：
location / {
include uwsgi_params;
uwsgi_pass localhost:9000;
}
uwsgi_bind address | off;
nginx所在的服务器可能有多个ip地址，uwsgi_bind指令用于设置nginx向后端的uwsgi服务器发起请求的时候，所使用的ip地址；如果没有指定的话，操作系统会自动委派一个本地的ip地址，向后端uwsgi服务器发起请求。
uwsgi_buffering on | off;
开启或关闭对uwsgi服务器的响应的缓冲 当开启缓冲的时候，nginx会从uwsgi服务器接收响应，并保存到uwsgi_buffer_size和uwsgi_buffers指令所设置的缓冲区中，如果整个响应超过了内存缓冲区的大小，一部分响应会被保存到磁盘的临时文件中。要写到的临时文件是由uwsgi_max_temp_file_size和uwsgi_temp_file_write_size这两个指令控制的， 当关闭缓冲的时候，响应会被同步的传递到客户端，也就是：响应被nginx收到就立刻传递给客户端，nginx不会尝试从后端的uwsgi服务器读取全部的响应，nginx每次能够从uwsgi服务器收到的数据的大小是由uwsgi_buffer_size指令设置的。
缓冲也可以通过在X-Accel-Buffering头域中传递yes或no来开启或关闭，在使用uwsgi_ignore_headers指令的时候，这项功能能够被禁用。
uwsgi_buffer_size size;
Default:uwsgi_buffer_size 4k|8k;
设置用于读取从uwsgi服务器收到的响应的第一部分的缓冲区的大小，这部分通常包含一个小的响应头，默认情况下，这个缓冲区的大小等于由uwsgi_buffers指令所设置的一个缓冲区的大小，然而，也可以把这个缓冲区设小。
uwsgi_buffers number size;
Default:uwsgi_buffers 8 4k|8k;
对一个单独的连接，设置用于读取uwsgi的响应的缓冲区的个数和大小，默认情况下，每个缓冲区的大小等于一个内存页面的大小，根据不同的平台，可能是4k或8k。
uwsgi_busy_buffers_size size;
Default:uwsgi_busy_buffers_size 8k|16k;
当开启了缓冲并且响应还没有被完全读完的时候，限制用于向客户端发送响应的缓冲区的大小，同时，其他的缓冲区仍然用于读取响应，缓冲区用尽的时候，也会把部分响应缓冲到临时文件。
默认情况下size被限制为uwsgi_buffer_size和uwsgi_buffers指令所设置的两个缓冲区的大小。
uwsgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [loader_files=number] [loader_sleep=time] [loader_threshold=time];
Context:http
设置缓存的目录和其他参数，缓存的数据被存储在文件中，每一个cache的文件名是对cache_key应用md5函数的结果，levels参数定义了cache的层级，比如下面的配置：
uwsgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;
一个cache的文件名看起来是这样的：
/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c
（levels=1:2，表示缓存目录的第一级目录有一个字符，第二级目录有两个字符） 一个被缓存的响应首先会被写入到一个临时文件，然后再重命名这个临时文件，临时文件和缓存文件可以放在不同的文件系统上，保存临时文件的目录是由use_temp_path参数设置的，如果这个参数被设置为on的话，那么由uwsgi_temp_path指令指定的目录就会被使用，否则的话，临时文件会被放到和缓存文件相同的目录。
此外所有活跃的key和数据都会被存储在一个共享内存空间内，共享内存空间的名字和大小是由keys_zone参数设置的，1M空间能存储大约8k个key。
被缓存的数据在inactive参数所指定的时间内没有被访问的话，就会被cache manager进程移除，inactive的默认值是10m。
cache manager进程会监控max_size参数所指定的最大缓存大小，一旦达到上限，cache manager进程就会按照lru算法移除数据。
nginx启动一分钟之后，cache loader进程会被激活，它把之前存储在文件系统上的缓存数据加载到缓存空间。加载以迭代的方式进行，在一个迭代期间，会加载不超过loader_files参数所指定的元素，并且一个迭代的时间不能超过loader_threshold参数所指定的值，两个迭代的时间间隔由loader_sleep参数指定。
uwsgi_cache_purge
nginx+ 提供的功能。
uwsgi_cache zone | off; Default:uwsgi_cache off;
定义用于缓存的共享内存空间，相同的zone可以被多个地方使用，参数值可以包含变量（1.7.9），off表示关闭缓存。
uwsgi_cache_bypass string ...;
定义不从缓存中取响应的条件，当string参数中至少有一个非空且不为0，就不会从缓存中取响应。
uwsgi_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
uwsgi_cache_bypass $http_pragma $http_authorization;
uwsgi_cache_key string;
定义用于缓存的key
uwsgi_cache_key localhost:9000$request_uri;
uwsgi_cache_methods GET | HEAD | POST ...;
Default:uwsgi_cache_methods GET HEAD;
Context:http, server, location
客户端的请求方法在这个指令中列出来时，响应才会被缓存，官网建议，显式的指定这个指令。
uwsgi_cache_min_uses number;
Default:uwsgi_cache_min_uses 1;
请求的数量达到这个指令设置的值之后，响应才会被缓存。
uwsgi_cache_valid [code ...] time;
对不同的状态码设置缓存时间。
比如：uwsgi_cache_valid 200 302 10m;表示对状态码为200和302的响应缓存10分钟。
uwsgi_connect_timeout time;
Default:uwsgi_connect_timeout 60s;
定义了nginx与后端的uwsgi服务器建立连接的超时时间，不应该超过75秒。
uwsgi_force_ranges on | off;
Default:uwsgi_force_ranges off;
对缓存的响应和来自uwsgi服务器的响应都开启byte-range支持。
uwsgi_hide_header field;
默认情况下，nginx不会把uwsgi服务器的响应中的Status和X_Accel-...头域传递给客户端，uwsgi_hide_header指令可以设置其他不想传递给客户端的头域。
uwsgi_ignore_client_abort on | off;
Default:uwsgi_ignore_client_abort off;
用来决定：当客户端不等待响应而直接关闭连接的时候，nginx和uwsgi的连接是否关闭。
uwsgi_intercept_errors on | off;
Default:uwsgi_intercept_errors off;
用来决定：当uwsgi服务器的响应的状态码大于等于300的时候，传递给客户端，还是重定向给nginx交给error_page指令处理。
uwsgi_limit_rate rate;
Default:uwsgi_limit_rate 0;
限制从uwsgi服务器读取响应的速度，rate的单位是字节每秒，0表示关闭速率限制， 这个限制是针对单独的连接的，因此如果nginx并发的打开两个连接，那么速率的最大值就是指定的速率的两倍。
uwsgi_max_temp_file_size size;
Default:uwsgi_max_temp_file_size 1024m;
当缓冲uwsgi服务器的响应的时候，如果整个响应不能放到uwsgi_buffer_size和uwsgi_buffers指令设置的缓冲区， 部分响应会被保存到临时文件，这个指令设置了临时文件的大小。
一次性被写到临时文件的数据的大小由uwsgitempfilewritesize指令来设置。
uwsgi_next_upstream error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | off ...;
Default:uwsgi_next_upstream error timeout;
指定了在哪些情形下，请求会传递给下一个uwsgi服务器。
应该牢记：当且仅当还没有传递给客户端任何东西的时候，才可能把请求传递给下一个uwsgi服务器。
因此，如果在响应传输过程中发生错误或超时，修正它是不可能的。
uwsgi_next_upstream_timeout time;
Default:uwsgi_next_upstream_timeout 0;
限制把请求传递给下一个服务器所允许的超时时间，0表示不限制。
uwsgi_next_upstream_tries number;
Default:uwsgi_next_upstream_tries 0;
限制把请求传递给下一个服务器所允许的尝试次数，0表示不限制。
uwsgi_no_cache string ...;
定义了响应不被保存到缓存的条件。string参数中至少有一个非空且不为0的时候，响应不会被缓存。
uwsgi_no_cache $cookie_nocache $arg_nocache;。
uwsgi_param parameter value [if_not_empty];
设置一个传递给uwsgi服务器的参数，value可以包含文本，变量，以及二者的组合 标准的cgi环境变量应该作为uwsgi头提供。
如果指令提供了if_not_empty参数，那么value非空时，参数才会传递给uwsgi服务器。
uwsgi_pass [protocol://]address;
设置uwsgi服务器的协议和地址，协议可是uwsgi或suwsgi（uwsgi over ssl）； 地址可以是ip地址，域名，和可选的端口：
uwsgi_pass localhost:9000;
uwsgi_pass uwsgi://localhost:9000;
uwsgi_pass suwsgi://[2001:db8::1]:9090;
也可是unix socket：
uwsgi_pass unix:/tmp/uwsgi.socket;
另外地址也可以被指定为server group。
uwsgi_pass_request_body on | off;
Default:uwsgi_pass_request_body on;
预示着是否把原始的请求体传递给uwsgi服务器。
uwsgi_pass_request_headers on | off;
Default:uwsgi_pass_request_headers on;
预示着是否把原始的请求头传递给uwsgi服务器。
uwsgi_read_timeout time;
Default:uwsgi_read_timeout 60s;
定义从uwsgi服务器读取响应的超时时间，如果在超时时间内uwsgi服务器没有传输任何东西，连接会被断开。
uwsgi_send_timeout time;
Default:uwsgi_send_timeout 60s;
定义向uwsgi服务器传输请求的超时时间，如果在超时时间内uwsgi服务器没有收到任何东西，连接会被断开。
uwsgi_store on | off | string;
Default:uwsgi_store off;
开启保存文件到磁盘，on参数表示用root或alias指令所指定的目录来保存文件，off参数表示不保存文件， 另外，文件名可以显式的使用string来设置：
uwsgi_store $document_root${uri}_$arg_docID;
响应首先会被写到临时文件，然后再重命名，保存临时文件的目录是由uwsgi_temp_path指令设置的。
uwsgi_store_access users:permissions ...;
Default:uwsgi_store_access user:rw;
设置新创建的文件和目录的访问权限。
uwsgi_temp_file_write_size size;
Default:uwsgi_temp_file_write_size 8k|16k;
当缓冲uwsgi服务器的响应到临时文件的时候，限制一次写入到临时文件的数据的大小。临时文件的最大的大小是由uwsgi_max_temp_file_size指令设置的。
uwsgi_temp_path path [level1 [level2 [level3]]];
Default:uwsgi_temp_path uwsgi_temp;
定义了存储从uwsgi服务器收到的数据的临时文件所在的目录，分为三级子目录。
比如：
uwsgi_temp_path /spool/nginx/uwsgi_temp 1 2;
临时文件可能是：
/spool/nginx/uwsgi_temp/7/45/00000123457传递到uWSGI服务器的参数
被传递到uWSGI服务器的请求头是以参数形式提供的，例如，User-agent头将会通过HTTP_USER_AGENT参数来传递，除了HTTP请求头之外，还可以通过uwsgi_param指令来传递任意参数。
uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;
uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;uwsgi的启动模式
VirtualHost模式：启动uwsgi时指定vhost选项。
preforking+threaded模式：启动uwsgi时指定processes和threads选项。
使用配置（！！！vhost模式！！！）
下面这个例子中，由单个uwsgi后台服务器实例提供了多个主机名称 和 单个主机有多个应用的情况。
upstream uwsgi_host
{
server 127.0.0.1:1088;
}
include uwsgi_params;
uwsgi_param SCRIPT_NAME $app;
uwsgi_param UWSGI_MODULE $app;
uwsgi_param UWSGI_CALLABLE "${app}_handler";
uwsgi_param UWSGI_PYHOME $document_root;
uwsgi_param UWSGI_CHDIR $document_root;
uwsgi_modifier1 30; #properly sets PATH_INFO variable
server
{
server_name foo;
root /var/www/foo;
location /app1/
{
set $app app1;
uwsgi_pass 127.0.0.1:1088;
}
location /app2/
{
set $app app2;
uwsgi_pass 127.0.0.1:1088;
}
}
server
{
server_name bar;
root /var/www/bar;
location /app1/
{
set $app app1;
uwsgi_pass uwsgi_host;
}
location /app3/
{
set $app app3;
uwsgi_pass uwsgi_host;
}
}在这个配置文件中提供了两个域名foo和bar，每个域名下都有两个应用。
在这个配置中使用了uwsgi协议的两个参数：SCRIPT_NAME和SERVER_NAME，SERVER_NAME在uwsgi_params文件中被映射，而SCRIPT_NAME被明确地传递到uWSGI服务器，这是因为在uWSGI的vhost应用名册上将键值设定为"host|script"格式。
具有相同的主机和相同的脚本名称的请求，才会交给相同的应用程序来处理。
如果没有提供脚本名称，那么就会为空，另外，第一次访问该脚本时首先会被初始化。
这是第一次访问：
WSGI application 2 (SCRIPT_NAME=bar|app3) ready on interpreter 0x8272860 pid: 21532
bar [pid: 21532|app: 2|req: 1/10] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:03 2011] GET /app3/ => generated 4 bytes in 20 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0)这是第二次访问：
bar [pid: 21527|app: 2|req: 2/11] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:07 2011] GET /app3/ => generated 4 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0)以下是三个app：
app1.py
def app1_handler(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return b'app1'
app2.py
def app2_handler(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return b'app2'
app3.py
def app3_handler(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return b'app3'例子中出现的uwsgi参数的说明：
UWSGI_PYHOME：向PYTHONPATH中增加一个目录。
UWSGI_CHDIR：改变uWSGI的工作目录。
UWSGI_MODULE：为WSGI应用程序提供入口，也就是WSGI应用程序所在的模块，它所在的目录应该在sys.path中。
UWSGI_CALLABLE：WSGI应用程序的名称。
如何正确设置PATH_INFO
nginx传递给uwsgi的PATH_INFO的值为uwsgi_param指令设置的PATH_INFO的值从第len(SCRIPT_NAME)个字符开始的部分（其中len(SCRIPT_NAME)为SCRIPT_NAME的值的长度）。
比如：SCRIPT_NAME被设置为app1，PATH_INFO被设置为$document_uri，那么在访问/app1的时候，nginx传递给uWSGI的PATH_INFO的值为"1"；而如果PATH_INFO被设置为$script$document_uri，那么在访问/app1的时候，nginx传递给uWSGI的PATH_INFO的值为/app1。
Tag标签:「nginx uwsgi 模块」更新时间:「2021-11-02 20:39:34」阅读次数:「927」