WEB服务器方面的调优

WEB服务器方面的调优

时间：2010-7-22

整理博客中全部有关WEB服务器性能调优方面的相关资料集合

一、解决resin自动重启的问题

想让resin能够动态加载class文件有三个条件：

高版本的resin

与之相配的JDK

以-Xdebug方式启动

 

二、查看apache并发请求数及TCP连接状态

2.1 查看httpd进程数

ps -ef | grep httpd | wc –l

查看apache的并发请求数及其TCP连接状态

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

说明返回结果的含义：

状态：描述
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫  表示正在监听请求
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态   表示建立了TCP连接开始正常传送数据
FIN_WAIT1：应用说它已经完成        应用完成掉
FIN_WAIT2：另一边已同意释放       
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放 
LAST_ACK：等待所有分组死掉

 

三、nginx实现upstream的几种分配方式

轮询（默认）

每个请求按顺序分配到不同的后端服务器，如果后端服务器一旦down掉就自动踢掉

weight

如果后端服务器性能不均的情况下可以采用这种权重的方式进行轮询

upstream bakend {
server 192.168.1.10 weight=10;
server 192.168.1.11 weight=10;

}

ip_hash

每个请求按访问的ip的hash结果分配，这样每个访客固定访问了一个后端服务器，可以解决session的问题。

upstream resinserver{
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}

fair(第三方)

按后端服务器的响应时间来分配，响应时间短的就优先分配

upstream resinserver{
server server1;
server server2;
fair;

}

url_hash(第三方)

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。（后端如果是带squid的话效果要好能够实现更好的缓存效果）

upstream resinserver{
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

 

四、nginx自定义错误页面

error_page 404 /404.html;
或者
error_page 404
同样的方式可以定义常见的403、500等错误
注意404页面大小要超过512k，不然会被ie浏览器替换为ie默认的错误页面。

 

五、限制nginx的并发连接数

limit_zone   limit  $binary_remote_addr  10m;
server {
location /download/ {
limit_conn   limit  1;
}

说明：$binary_remote_addr长度为4bytes而会话信息的长度为32bytes或64.

如果我们将区的大小设置为1M的时候大概能够容纳32000个会话信息。表示可以建立这么多的会话。

但是一个会话最多会有多少个并发连接数呢？这个是由limit_conn   limit  1;来控制

limit_zone   limit  $binary_remote_addr  10m;
定义一个叫“limit”的记录区，总容量为 10M，以变量 $binary_remote_addr 作为会话的判断基准（即一个地址一个会话）。
您可以注意到了，在这里使用的是 $binary_remote_addr 而不是 $remote_addr。
$remote_addr 的长度为 7 至 15 bytes，会话信息的长度为 32 或 64 bytes。 而 $binary_remote_addr 的长度为 4 bytes，会话信息的长度为 32 bytes。
当区的大小为 1M 的时候，大约可以记录 32000 个会话信息（一个会话占用 32 bytes）。
limit_conn   limit  1;
指定一个会话最大的并发连接数。 当超过指定的最发并发连接数时，服务器将返回 "Service unavailable" (503)

 

六、nginx 400 bad request错误原因与解决方法

HTTP请求头过大主要原因是COOKIE写入了较大的值引起的。而HTTP请求头过大的情况下会导致服务不可用即400请求失败的问题。针对这个问题解决方案：

在nginx.conf中，将client_header_buffer_size和large_client_header_buffers都调大，可缓解此问题。

client_header_buffer_size 16k;
large_client_header_buffers 4 64k;
这个配置可接收16k以下的header，在浏览器中cookie的字节数上限会非常大，所以实在是不好去使用那最大值。

 

七、nginx 502 bad gateway解决办法

出现的原因是FastCGI的问题。解决方法：

7.1 检查FastCGI进程是否已经启动

netstat -tlnp|grep 8055|awk '{print $7}'|awk -F '/' '{print $1}'

7.2 FastCGI 的worker进程数是否不够

运行 netstat -anpo | grep "php-cgi" | wc -l 判断是否接近FastCGI进程，接近配置文件中设置的数值，表明worker进程数设置太少

7.3 FastCGI执行时间过长

根据实际情况调高以下参数值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
如果你的应用过于复杂这个时间值可以适当地配置长一点的！可能会超时

7.4 FastCGI Buffer不够

如果你用了Proxying，调整
proxy_buffer_size  16k;
proxy_buffers      4 16k;

7.5 https转发配置错误

server_name
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass
}

 

 

八、nginx 报错413 请求实体太大

这种情况经常会出现在上传文件的时候。上传文件默认大小为1M。如果超过了这个阀值的话就要适当地增大。client_max_body_size 30m;

 

九、使用nginx的url hash提高squid的命中率

说明：这个之前我们在前面介绍nginx的时候有提过的！

一般现行的架构通常是使用dns轮询或lvs等将访问量负载均衡到数台squid，这样做可以使 squid的访问量做到了均衡，但是忽略了一个重要方面–数据量。在这种架构下，每台squid的数据量虽然是一致的，但通常都是满载，并且存在数据重复 缓存的情况。如果后端服务器数据容量或者用户的访问热点数远远超过缓存机器的内存容量，甚至配置的disk cache容量，那么squid将会大量使用磁盘或者不停与后端服务器索取内容。

具体配置：

nginx本身并没有提供url hash功能（暂时），需要安装第三方模块ngx_http_upstream_hash_module

     下载

cd nginx-0.5.xx

patch -p0 < /path/to/upstream/hash/directory/nginx-0.5.xx.patch 补丁

./configure时加上参数

–add-module=path/to/upstream/hash/directory

make; make install

完成安装

配置：

在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}