官方文档地址: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」阅读次数:「913」