转载：http://salogs.com
测试目标
（1）弄清楚HTTP Upstream 模块中Server指令的max_fails与fail_timeout参数的关系、它们对后端办事器健康景象的搜检起到了什么感化、它们的取值对Http proxy模块中的其它指令是否有直接或间接的影响等&＃8230;&＃8230;
（2）测试HTTP Proxy模块中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、 proxy_send_timeout指令的感化、对nginx机能的影响、对后端办事器响应的处理惩罚等&＃8230;&＃8230;
测试办法
本文测试不会应用压力测试，所有的测试都是经由过程浏览器手动刷新来实现的。后端办事器应用简单的php法度来实现。
测试景象
Nginx负载均衡/反向****代理办事器
体系：CentOS 5.4 64bit
Nginx：0.7.65
IP:192.168.108.10
后端web办事器
体系：CentOS 5.4 64bit
Web景象：apache+php
Web-1 IP:192.168.108.163
Web-2 IP:192.168.108.164
本次测试首要针对HTTP Upstream和HTTP Proxy模块进行，下面测试景象中http upstream 和http proxy模块参数的初始化设置，后文会针对测试的参数进行响应的批改：
upstream test {
server 192.168.108.163 ;
server 192.168.108.164: 80;
}
server {
listen 80;
server_name .test.com;
index index.php index.html index.htm;
location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
proxy_connect_timeout 10s;
proxy_read_timeout 2s;
＃proxy_send_timeout 10s;
proxy_pass http: // test;
}
}
&＃8230;
提出server指令后面的参数项目组，以下摘抄nginx wiki 内容
语法：server name [parameters]
parameters包含：
&＃183;weight = NUMBER - 设置办事器权重，默认为1。
&＃183;max_fails = NUMBER - 在一按时候内（这个时候在fail_timeout参数中设置）搜检这个办事器是否可用时产生的最多失败恳求数，默认为1，将其设置为0可以封闭搜检，这 些错误在proxy_next_upstream或fastcgi_next_upstream（404错误不会使max_fails增长）中定义。
&＃183;fail_timeout = TIME - 在这个时候内产生了max_fails所设置大小的失败测验测验连接恳求后这个办事器可能不成用，同样它指定了办事器不成用的时候（鄙人一次测验测验连接恳求创议 之前），默认为10秒，fail_timeout与前端响应时候没有直接关系，不过可以应用proxy_connect_timeout和 proxy_read_timeout来把握。
&＃183;down - 标识表记标帜办事器处于离线状况，凡是和ip_hash一路应用。
&＃183;backup - （0.6.7或更高）只用于本办事器，若是所有的非备份办事器都宕机或繁忙。
关于max_fails参数的懂得：按照上方的申明，max_fails默认为1，fail_timeout默认为10秒，也就是说，默认景象下后端办事器在10秒钟之内可以容许有一次的失败，若是跨越1次则视为该办事器有题目，将该办事器标识表记标帜为不成用。守候10秒后再将恳求发给该办事器，以此类推动行后端办事器的健康搜检。但若是我将max_fails设置为0，则代表不合错误后端办事器进行健康搜检，如许一来fail_timeout参数也就没什么意义了。那若后端办事器真的呈现题目怎么办呢？上文也说了，可以借助proxy_connect_timeout和proxy_read_timeout进行把握。
下面介绍http proxy模块中的相干指令：
proxy_next_upstream
语法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
断定在何种景象下恳求将转发到下一个办事器。转发恳求只产生在没稀有据传递到客户端的过程中。
proxy_connect_timeout
后端办事器连接的超不时候_创议握手等待响应超不时候
proxy_read_timeout
连接成功后_等待后端办事器响应时候_其实已经进入后端的列队之中等待处理惩罚（也可以说是后端办事器处理惩罚恳求的时候）
proxy_send_timeout
后端办事器数据回传时候_就是在规按时候之内后端办事器必须传完所有的数据
proxy_pass
这个指令设置被****代理办事器的地址和被映射的URI
开端测试
景象1：后端法度履行时候跨越或便是proxy_read_timeout设置值，max_fails=0 封闭后端办事器健康搜检。
| Nginx设备批改内容 | server 192.168.108.163 max_fails = 0; server 192.168.108.164 max_fails = 0; proxy_next_upstream error timeout proxy_read_timeout 2s |
| 后端web办事器 | |
| Web1 test.php | Web2 test.php |
| <？php header（""RS:Web1""）; ￥t = 2; sleep（￥t）; echo "sleep {￥t}s<br>"; echo "web-1<br>"; ？> | <？php header（""RS:Web2""）; ￥t = 5; sleep（￥t）; echo "sleep {￥t}s<br>"; echo "web-2<br>"; ？> |
| 备注： 我这里的两台后端web办事器，他们的主页文件均为一个test.php法度，该法度分别sleep了2秒和5秒，便是和跨越了 proxy_read_timeout的时候，[max_fails=0] 即封闭后端办事器健康搜检。[proxy_next_upstream error timeout] 申明碰着错误或超时的景象切到下一个后端办事器。如此设置后哄骗curl号令对nginx创议连接恳求，看nginx会作何反响。 | |
| 测试开端： （1）curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 4.008:0.002:4.007 申明： 连气儿恳求3次后获得的http返回成果是一样的，均为504 Gateway Time-out 错误。这种景象只有在后端办事器都有题目的时才会呈现这个错误，很显然我这里的proxy_read_timeout设置的时候太短，后端法度还没来得及 把法度履行完，nginx就火烧眉毛的将恳求甩给upstream定义的另一台办事器上了，当发明别的一台办事器同样2秒没有返回后，nginx这回没有 办事器可用，只有返回504 Gateway Time-out 。这也是为什么最后的time_total时候是4秒。（经查看两台web办事器的接见日记得知，均有一条接见记录，且返回代码为200，申明nginx 确切来过，但没有比及履行完成绩促的离去了）若是我有3台办事器，在包管任何不变的景象下，time_total时候必然会是6秒，因为nginx会一 个接一个的将3台办事器都走一遍。 ----------------------------------------------------------------------------------------------------------------------- 好了，确认是我proxy_read_timeout设置时候太短后，我将它的值设置为3秒，再经由过程curl号令接见： （2）curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 5.042:0.005:5.042 申明：经由过程3次连气儿恳求，获得的成果是一样的，RS:Web1 也就是说我这三次的恳求都甩到了web1上。但我web1中的法度只须要2秒后就可以返回成果，但为什么我经由过程nginx****代理后时候老是我的 法度履行时候+proxy_read_timeout时候呢？ ----------------------------------------------------------------------------------------------------------------------- 持续将proxy_read_timeout设置为4s （3）curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 6.004:0.000:6.004 三次恳求后成果也是一样，此次花的时候更长了，但确切是法度履行时候+proxy_read_timeout 时 间。但为什么每次都须要6秒呢？遵守upstream中定义的权重应当是等分恳求的，最起码应当有2秒的时辰。经过解析得知：终极返回给用户恳求的是 web1，那么当再次恳求的时辰必然会分给web2，因为web2是sleep 5秒的，是以经过proxy_read_timeout的时候（4s）后会跳到web1，成果还是web1返回的恳求，所花时候就是nginx在web2 守候的时候+web1履行的时候，以此类推下一次nginx天然的还会分给web2&＃8230;&＃8230;。若是有更多的后端web，则断定下一个恳求办事器可以看当前返回 给终极用户的是那台办事器，然后按照upstream中定义的次序向下查询（权重一样的景象） | |
| 结论： （1）上方的三次测试分别将proxy_read_timeout的值设置为2s、3s、4s的景象进行的。终极的测试成果也都在后面做了申明与说 明。因为我封闭了后端办事器的健康搜检（max_fails=0）是以断定后端办事器景象的独一根据便是proxy_read_timeout参数，若是 这个参数设置得过小，但后端法度的履行或多或少会跨越这个时候的话，这种景象nginx的效力是很是低的。 （2）上方的测试都是后端办事器正常但履行超时的景象下nginx按照proxy_read_timeout和 proxy_next_upstream的值来选择下一个办事器，那若是我后端办事器直接报错的景象呢？可以想到若是报错信息在 proxy_next_upstream 中有定义的话nginx还会跳到下一台办事器。不然直接将保存信息返回给nginx从而终极呈献给用户 | |
景象2：打开后端办事器健康搜检，测试法度履行时候跨越或便是proxy_read_timeout值或后端办事器直接报错的景象
| Nginx设备批改内容 | server 192.168.108.163 max_fails = 1; server 192.168.108.164 max_fails = 1; proxy_next_upstream error timeout http_500 http_502 http_504 proxy_read_timeout 2s | |
| 后端web办事器 | ||
| Web1 test.php | Web2 test.php | |
| <？php header（""RS:Web1""）; ￥t = 2; sleep（￥t）; echo "sleep {￥t}s<br>"; echo "web-1<br>"; ？> | <？php header（""RS:Web2""）; header（""http/1.1 500 Internal Server Error ""）; ＃￥t = 5; ＃sleep（￥t）; echo "sleep {￥t}s<br>"; echo "web-2<br>"; ？> | |
| 备注： 开启了后端办事器健康搜检 | ||
| 测试开端： （1）连气儿测试三次成果如下： curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 0.001:0.001:0.001 curl -I -w ％{time_total}:％{time_connect}:％{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 申明： 第1次恳求所用时候是2秒，web1履行超时，web2返回了500错误，upstream没有更多的后端，是以nginx直接把504扔出来了，同时标识表记标帜web2，web1不成用。查看后端2台web办事器的接见日记，均有nginx****代理的接见记录。 （2）批改 proxy_read_timeout 3s 连气儿接见6次后成果以及2台web办事器的日记景象 2.003:0.001:2.002 接见日记 Web1 Web2 [18/May/2010:15:30:00 申明： 由接见日记可知： | ||
| 结论： （1）proxy_next_upstream参数很有效，他可以避免很多错误 | ||
1.是否超时，是由 proxy_read_timeout 决意的。
2.若是后端没有设置健康搜检， 则每次恳求都邑最多守候 proxy_read_timeout 时候，若是跨越该时候没有响应，则测验测验下一个办事器。 周而复始。
下次恳求时，恳求将不再发送给该办事器，一向比及 标识表记标帜为不成用的时候-fail_timeout过后，才会再将恳求转发给刚才标识表记标帜为不成用的那台办事器。
如此周而复始
扫一扫
1725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
