额头正中央偏下有痣:nginx c-cgi

测试目的
（1）弄清楚HTTP Upstream 模块中Server指令的max_fails与fail_timeout参数的关系、它们对后端服务器健康情况的检查起到了什么作用、它们的取值对Http proxy模块中的其它指令是否有直接或间接的影响等……
（2）测试HTTP Proxy模块中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout指令的作用、对nginx性能的影响、对后端服务器响应的处理等……
测试方法
本文测试不会使用压力测试，所有的测试都是通过浏览器手动刷新来实现的。后端服务器使用简单的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;
}
}
…
提出server指令后面的参数部分，以下摘抄nginx wiki 内容
语法：server name [parameters]
parameters包含：
·weight = NUMBER - 设置服务器权重，默认为1。
·max_fails = NUMBER - 在一定时间内（这个时间在fail_timeout参数中设置）检查这个服务器是否可用时产生的最多失败请求数，默认为1，将其设置为0可以关闭检查，这些错误在proxy_next_upstream或fastcgi_next_upstream（404错误不会使max_fails增加）中定义。
·fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用，同样它指定了服务器不可用的时间（在下一次尝试连接请求发起之前），默认为10秒，fail_timeout与前端响应时间没有直接关系，不过可以使用proxy_connect_timeout和 proxy_read_timeout来控制。
·down - 标记服务器处于离线状态，通常和ip_hash一起使用。
·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
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s
";
echo "web-1
";
?> header('RS:Web2');
$t = 5;
sleep($t);
echo "sleep {$t}s
";
echo "web-2
";
?>
备注：
 
我这里的两台后端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
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 02:43:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive
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
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:07:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1
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
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:15:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1
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……。如果有更多的后端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
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s
";
echo "web-1
";
?> header('RS:Web2');
header('http/1.1 500 Internal Server Error ');
#$t = 5;
#sleep($t);
echo "sleep {$t}s
";
echo "web-2
";
?>
备注：
 
开启了后端服务器健康检查
proxy_read_timeout 2s （下面会随着测试变更）
Web1程序仍然sleep 2s
修改了Web2程序，让他直接返回500错误
测试开始：
 
（1）连续测试三次结果如下：
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:48 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive
2.005:0.001:2.005
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 502 Bad Gateway
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:50 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 173
Connection: keep-alive
0.001:0.001:0.001
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:57 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive
2.005:0.001:2.005
说明：
第1次请求所用时间是2秒，web1执行超时，web2返回了500错误，upstream没有更多的后端，因此nginx直接把504扔出来了，同时标记web2，web1不可用。查看后端2台web服务器的访问日志，均有nginx代理的访问记录。
第2次请求时间很短，报502错误，说明没有可用的后端服务器接受请求。查看后端两台web服务器访问日志，没有任何变化，说明这两台服务器被nginx标记为不可用，没有把请求转向后端，直接返回用户502错误
第3次请求同第1次
（2）修改 proxy_read_timeout 3s 连续访问6次后结果以及2台web服务器的日志情况
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:30:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1
2.003:0.001:2.002
访问日志
Web1
[18/May/2010:15:30:00
[18/May/2010:15:30:03
[18/May/2010:15:30:05
[18/May/2010:15:30:08
[18/May/2010:15:30:11
[18/May/2010:15:30:13
Web2
[18/May/2010:15:30:00
[18/May/2010:15:30:11
说明：
由访问日志可知：
第1次请求是被分到web2上的，由于它返回了500错误，因此请求被转到web1，并标记web2不可用。
第2次至第4次均将请求给了web1，第四次请求完毕后距第一请求已经过去了8秒。
第5次请求时已经是fail_timeout参数默认的10s也就是标记web2不可用的时间已经过去了，因此在第5次访问实际上和第一次情况是一样的。
结论：
 
（1）proxy_next_upstream参数很有用，他可以避免很多错误
（2）max_fails 参数在繁忙的大型系统中建议设置为3，如果没有几个后端服务器的话保持默认即可。
（3）proxy_read_timeout要根据自身程序而定，不要过大，也不要太小。如果是php程序，请参照php.ini中的max_execution_time选项值。
原创文章，转载请注明:   转自 http://salogs.com
linux网络服务,Nginxnginx
Nginx做负载均衡时X-Forwarded-For信息头的处理
2010/04/23 于 16:19Cooper抢沙发
如今利用nginx做负载均衡的实例已经很多了，针对不同的应用场合，还有很多需要注意的地方，本文要说的就是在通过CDN 后到达nginx做负载均衡时请求头中的X-Forwarded-For项到底发生了什么变化。下图为简单的web架构图：

nginx 负载均衡
先来看一下X-Forwarded-For的定义：
X-Forwarded-For:简称XFF头，它代表客户端，也就是HTTP的请求端真实的IP，只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项。它不是RFC中定义的标准请求头信息，在squid缓存代理服务器开发文档中可以找到该项的详细介绍。
标准格式如下：
X-Forwarded-For: client1, proxy1, proxy2
从标准格式可以看出，X-Forwarded-For头信息可以有多个，中间用逗号分隔，第一项为真实的客户端ip，剩下的就是曾经经过的代理或负载均衡的ip地址，经过几个就会出现几个。
按照上图的Web架构图，可以很容易的看出，当用户请求经过CDN后到达Nginx负载均衡服务器时，其X-Forwarded-For头信息应该为 客户端IP,CDN的IP 但实际情况并非如此，一般情况下CDN服务商为了自身安全考虑会将这个信息做些改动，只保留客户端IP。我们可以通过php程序获得X-Forwarded-For信息或者通过Nginx的add header方法来设置返回头来查看。
下面来分析请求头到达Nginx负载均衡服务器的情况；在默认情况下，Nginx并不会对X-Forwarded-For头做任何的处理，除非用户使用proxy_set_header 参数设置：
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
$proxy_add_x_forwarded_for变量包含客户端请求头中的"X-Forwarded-For"，与$remote_addr用逗号分开，如果没有"X-Forwarded-For" 请求头，则$proxy_add_x_forwarded_for等于$remote_addr。
$remote_addr变量的值是客户端的IP
当Nginx设置X-Forwarded-For等于$proxy_add_x_forwarded_for后会有两种情况发生
1、如果从CDN过来的请求没有设置X-Forwarded-For头（通常这种事情不会发生），而到了我们这里Nginx设置将其设置为$proxy_add_x_forwarded_for的话，X-Forwarded-For的信息应该为CDN的IP，因为相对于Nginx负载均衡来说客户端即为CDN，这样的话，后端的web程序时死活也获得不了真实用户的IP的。
2、CDN设置了X-Forwarded-For，我们这里又设置了一次，且值为$proxy_add_x_forwarded_for的话，那么X-Forwarded-For的内容变成 ”客户端IP,Nginx负载均衡服务器IP“如果是这种情况的话，那后端的程序通过X-Forwarded-For获得客户端IP，则取逗号分隔的第一项即可。
如上两点所说，如果我们知道了CDN设置了X-Forwarded-For信息，且只有客户端真实的IP的话，那么我们的Nginx负载均衡服务器可以不必理会该头，让它默认即可。
其实Nginx中还有一个$http_x_forwarded_for变量，这个变量中保存的内容就是请求中的X-Forwarded-For信息。如果后端获得X-Forwarded-For信息的程序兼容性不好的话（没有考虑到X-Forwarded-For含有多个IP的情况），最好就不要将X-Forwarded-For设置为 $proxy_add_x_forwarded_for。应该设置为$http_x_forwarded_for或者干脆不设置！
参考文章：http://en.wikipedia.org/wiki/X-Forwarded-For
原创文章，转载请注明: 转自 http://salogs.com
Nginx,负载均衡linux网络服务,nginx,负载均衡
告别LVS—使用keepalived+nginx实现负载均衡代理多个HTTPS
2010/03/08 于 09:58Cooper抢沙发

需求1：CDN小节点使用尽可能少的资源实现高可用和负载均衡
需求2：需要支持10多个HTTPS站点的反向代理
后端环境：nginx在前端做url_hash，后端缓存服务器使用squid和lighttpd分别处理动静态内容，服务器证书在nginx上
解决方案：
使用keepalived来实现前端3台nginx的高可用，DNS轮询来均摊负载。
每个https站点使用一个独立IP，非https站点分摊到这些IP上。
在每台机器的lo上绑定所有的IP来启动nginx服务。
架构图：

原理：
正常情况下负载均摊，每台机器只负担2-3个HTTPS站点，比如此时nginxA只负责192.168.0.101和192.168.0.102这2个HTTPS站点。当nginxB挂掉时，nginxA和nginxC会根据策略去分担192.168.0.103和192.168.0.104这2个站点的访问，这时nginxA上负担的站点就可能就是192.168.0.101、192.168.0.102和192.168.0.104了。
分配策略：

lo绑ip脚本：
#!/bin/sh
echo '2' > /proc/sys/net/ipv4/conf/lo/arp_announce
echo '1' > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo '2' > /proc/sys/net/ipv4/conf/all/arp_announce
echo '1' > /proc/sys/net/ipv4/conf/all/arp_ignore
ifconfig lo:1 198.188.225.101 netmask 255.255.255.255
ifconfig lo:2 198.188.225.102 netmask 255.255.255.255
ifconfig lo:3 198.188.225.103 netmask 255.255.255.255
ifconfig lo:4 198.188.225.104 netmask 255.255.255.255
ifconfig lo:5 198.188.225.105 netmask 255.255.255.255
ifconfig lo:6 198.188.225.106 netmask 255.255.255.255
Ngnix A配置文件范例：
! Configuration File for keepalived
global_defs {
notification_email {
du@nli0n@snda.com
}
notification_email_from nginx_ha1@snda.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id nginx_ha1
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.101
192.168.0.102
}
}
vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.103
192.168.0.104
}
}
vrrp_instance VI_3 {
state BACKUP
interface eth0
virtual_router_id 53
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.105
192.168.0.106
}
}
linux网络服务,Nginx,负载均衡keepalived,LVS,nginx
nginx 内置变量列表
2009/09/24 于 17:01Cooper抢沙发
来自nginx wiki
The module ngx_http_core_module supports the built-in variables, whose names correspond with the names of variables in Apache.
First of all, these are the variables, which represent the lines of the title of the client request, for example:
$http_host
$http_user_agent
$http_referer
$http_via
$http_x_forwarded_for
$http_cookie
$content_length
$content_type
Furthermore, there are other variables:
$arg_PARAMETER, this variable contains the value of the GET request variable PARAMETER if present in the query string
$args, this variable is equal to arguments in the line of request;
$content_length, this variable is equal to line “Content-Length” in the header of request;
$content_type, this variable is equal to line “Content-Type” in the header of request;
$document_root, this variable is equal to the value of directive root for the current request;
$document_uri, the same as $uri;
$host, this variable is equal to line “Host” in the header of request or name of the server, to whom the request arrived, if there is no this line;
$is_args evaluates to “?” if $args is set, “” otherwise.
$limit_rate, the variable allows to limit connection rate;
$query_string, the same as $args;
$request_method, this variable is equal to the method of request, usually this “GET” or “POST”;
$remote_addr, this variable is equal to the address of client;
$remote_port, this variable is equal to the port of client;
$remote_user, this variable is equal to the name of user, authenticated by ngx_http_auth_basic_module;
$request_filename, this variable is equal to path to the file for the current request, formed from directives root or alias and URI request;
$request_body_file, client request body temporary filename;
$request_uri, this variable is equal to the complete initial URI together with the arguments;
$scheme, the HTTP scheme (http, https). Evaluated only on demand, for example:
rewrite ^(.+)$ $scheme://example.com$1 redirect;
$server_protocol, this variable is equal to the protocol of request, usually this “HTTP/1.0″ or “HTTP/1.1″;
$server_addr, the variable is equal to the server address, to whom arrived the request. As a rule, for obtaining the value of this variable is done one system call. In order to avoid system call, it is necessary to indicate addresses in directives listen and to use parameter bind;
$server_name, this variable is equal to the name of the server, to whom arrived the request;
$server_port, this variable is equal to the port of the server, to which the request arrived;
$uri, this variable is equal to current URI in the request, it can differ from initial, for example by internal redirects, or with the use of index it is file with internal redirects.
linux网络服务,Nginxlinux网络服务,nginx
nagios平台从apache迁移到nginx
2009/09/22 于 17:58Cooper抢沙发
nginx的性能远远优于apache，但由于nagios的web界面中包含php和c-cgi程序，因此需要两套fcgi管理工具（并非必须）和两套解释器（必须）。php用php-cgi跑就可以，c-cgi我选用fcgiwrap。下面介绍安装/配置步骤。
环境介绍：
先前环境：apache+php+nagios 除了nagios 其余的都使用yum自动安装
目标环境：nginx+php5.2.10(php-fpm patch)+nagios 均为源码编译安装
php-fpm：是为PHP打的一个FastCGI管理补丁，可以平滑变更php.ini配置而无需重启php-cgi
Spawn-fcgi：是lighttpd的一个分支项目，是一个cgi进程的管理器
● php 打php-fpm补丁，编译时启用--enable-fastcgi --enable-fpm 参数，使用php-fpm管理php-cgi。php安装详细步骤参见 张宴文章：http://blog.s135.com/nginx_php_v5/
● c-cgi 使用 Spawn-fcgi 管理 ，利用fcgiwrap驱动。fcgiwrap 介绍参见http://nginx.localdomain.pl/wiki/FcgiWrap
php-cgi 监听 127.0.0.1:9000
fcgiwrap 监听 127.0.0.1:10000
nagios 安装配置不是本文重点，略过。web 目录如下：
/usr/local/nagios/share
安装配置
yum install fcgi fcgi-devel -y
php-fpm 的配置与运行这里略过，下面主要讲解Spawn-fcgi+fcgiwrap 的安装与配置
spawn-fcgi
# wget http://www.lighttpd.net/download/spawn-fcgi-1.6.2.tar.gz
# tar -xvzf spawn-fcgi-1.6.2.tar.gz
# cd spawn-fcgi-1.6.2/
# ./configure
# make
# cp src/spawn-fcgi /usr/local/bin/
fcgiwrap
# wget http://github.com/gnosek/fcgiwrap/tarball/master
# tar -xvzf gnosek-fcgiwrap-28ac6f9aa5e7dadf9aaf2062ab003a0fb4c82ad8.tar.gz
# cd gnosek-fcgiwrap-28ac6f9aa5e7dadf9aaf2062ab003a0fb4c82ad8/
# make
# mv fcgiwrap /usr/local/bin/
创建一个shell脚本来用spawn-fcgi 启动fcgiwrap实例
# vi /usr/local/bin/c-fcgi.sh
#!/bin/sh
/usr/local/bin/spawn-fcgi -f /usr/local/bin/fcgiwrap -a 127.0.0.1 -p 10000 -F 3 -P /var/run/fastcgi-c.pid -u www -g www
# chmod +x /usr/local/bin/c-fcgi.sh
创建一个系统启动进程，方便使用service 和chkconfig 命令管理
# vi /etc/init.d/c-fcgi
#!/bin/bash
# c-fcgi - this script starts and stops the fcgiwrap instance
#
# chkconfig:   - 96 28
# description:  c-fcgi
# processname: c-fcgi
C_SCRIPT=/usr/local/bin/c-fcgi.sh
RETVAL=0
case "$1" in
start)
echo "Starting fastcgi"
$C_SCRIPT
RETVAL=$?
;;
stop)
echo "Stopping fastcgi"
killall -9 fcgiwrap
RETVAL=$?
;;
restart)
echo "Restarting fastcgi"
killall -9 fcgiwrap
$C_SCRIPT
RETVAL=$?
;;
*)
echo "Usage: c-fastcgi {start|stop|restart}"
exit 1
;;
esac
exit $RETVAL
# chkconfig --add c-fcgi
# chkconfig c-fcgi on
# service c-fcgi start
验证启动,是否提供了相应的端口
# netstat -tulnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      32629/php-cgi
tcp        0      0 127.0.0.1:10000             0.0.0.0:*                   LISTEN      20039/fcgiwrap
# ps -ef | grep fcgiwrap | grep -v grep
www      20039     1  0 15:20        00:00:00 /usr/local/bin/fcgiwrap
www      20040     1  0 15:20        00:00:00 /usr/local/bin/fcgiwrap
www      20041     1  0 15:20        00:00:00 /usr/local/bin/fcgiwrap
# ps -ef | grep php-cgi | grep -v grep
root     32629     1  0 13:37        00:00:00 /usr/local/php/bin/php-cgi --fpm --fpm-config /usr/local/php/etc/php-fpm.conf
.
.
.
www      32642 32629  0 13:37        00:00:00 /usr/local/php/bin/php-cgi --fpm --fpm-config /usr/local/php/etc/php-fpm.conf
我php-fpm配置启动32个php-cgi 实例
配置nginx
user                www www;
worker_cpu_affinity 0001 0010 0100 1000;
worker_processes        4;
# 可以在下方直接使用 [ debug | info | notice | warn | error | crit ]  参数
error_log   /usr/local/nginx/logs/nginx_error.log   crit;
pid     /var/run/nginx.pid;
#进程所能打开的最大文件描述符个数
worker_rlimit_nofile    51200;
events
{
# linux 2.6+ 版本以上的内核推荐使用 epoll 事件模式
use             epoll;
# 最大连接数=worker_processes*worker_connections/4
worker_connections  4096;
}
http
{
include     ./conf.d/mime.types;
default_type    application/octet-stream;
charset utf-8;
server_names_hash_bucket_size   128;
client_header_buffer_size       32k;
large_client_header_buffers     4   32k;
client_max_body_size            8m;
sendfile        on;
tcp_nopush  on;
keepalive_timeout   60;
tcp_nodelay     on;
# global fastcgi configure
include         ./conf.d/fastcgi_custom.conf;
# include fastcgi_params.conf
include               ./conf.d/fastcgi_params.conf;
# gzip configure
include         ./conf.d/gzip.conf;
#limit_zone  crawler  $binary_remote_addr  10m;
server
{
listen          80;
server_name     cacti.opt.jobkoo.com;
index           index.html index.htm index.php;
root            /data/www/cacti;
#limit_conn   crawler  20;
location ~ .*\.(php|php5)$
{
fastcgi_pass        127.0.0.1:9000;
fastcgi_index       index.php;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires     30d;
}
location ~ .*\.(js|css)$
{
expires     1h;
}
log_format  access  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log  /usr/local/nginx/logs/access.log  access;
}
server
{
listen          80;
server_name     nagios.opt.jobkoo.com;
index           index.html index.htm index.php;
root            /usr/local/nagios/share/;
auth_basic      "Welcome to Jobkoo Nagios Monitor System!";
auth_basic_user_file    ./conf.d/htpasswd;
# 这个rewrite针对的是pnp插件的鼠标移动到图标后显示的浮动窗
rewrite     ^/nagios/pnp/(.*)\.php /pnp/$1.php break;
# 以 cgi 结尾的文件
location ~ \.cgi$ {
root    /usr/local/nagios/sbin;
rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;
fastcgi_pass   127.0.0.1:10000;
fastcgi_index  index.cgi;
}
# 以 php/php5 结尾的文件
location ~ \.(php|php5)+$
{
fastcgi_pass        127.0.0.1:9000;
fastcgi_index       index.php;
}
log_format  wwwlogs  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log      /usr/local/nginx/logs/nagios.access.log  wwwlogs;
}
server
{
listen          80;
server_name     status.apt.jobkoo.com;
location / {
stub_status     on;
access_log      off;
}
}
}
/etc/nginx/conf.d 目录下的cgi 参数配置文件
#vi /etc/nginx/conf.d/fastcgi_custom.conf
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
# vi /etc/nginx/conf.d/fastcgi_params.conf
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;
设置nagios页面身份验证
# htpasswd -c /etc/nginx/conf.d/htpasswd admin
# cat /etc/nginx/conf.d/htpasswd
admin:QqbxsY3jdkOpQ
配置nagios
#vi /usr/local/nagios/etc/cgi.cfg
use_authentication=1
# service nagios start
# service nginx start
访问nagios页面

原创文章，转载请注明: 转自http://salogs.com