Nginx

虚拟机的网络性能大部分不好，使用nginx的时候经常会因为带宽的限制跑不到更高的QPS。这个时候可以开启gzip压缩，使得带宽占有成倍的减少。但是开启gzip压缩后有个很大的问题是CPU的消耗非常大。对于普通的精态页面可以考虑配置2个server，其中一个代理另外一个，并且开启cache。简单使用ab压测对比了一下，效果还可以。ab只支持HTTP 1.0，所以在nginx里需要配置一下gzip_http_version 1.0并且ab压测的时候使用添加HEADER ‘Accept-Encoding: gzip’。ab -c 50 -t 60 -H ‘Accept-Encoding: gzip’ http://xxx.net/index.html 配置大修改大致如下：``` http { proxy_cache_path /home/admin/temp levels=1:2 keys_zone=one:10m inactive=5m max_size=100m; gzip_http_version 1.0; #这个只是为了方便ab测试，线上的话可以关闭这个，防止有古董浏览器不支持gzip。gzip on; ………. server {listen 8888;server_name localhost;charset gbk;gzip on;gzip_comp_level 9;gzip_http_version 1.0;location / {root /home/admin/webpages/;index index.html;}}upstream indexpage {server 127.0.0.1:8888;keepalive 10;} } } Document Length:11155 bytesTotal transferred: 567657498 bytesHTML transferred: 557757300 bytesRequests per second:5123.96[#/sec] (mean)Time per request: 9.758 [ms] (mean)Time per request: 0.195 [ms] (mean, across all concurrent requests)Transfer rate: 56809.65 [Kbytes/sec] received 普通的不开启gzip的情况 Document Length:52873bytes ...

今天有专门测试对比了一下nginx和apache在jboss上次代理的性能。apache是通过jk模块使用ajp协议把请求转给java，nginx的测试是直接把jboss上开启一个HTTP 1.1端口服务进行测试。找开发写了一个简单的页面，对页面的处理就是sleep 4ms,jboss里配置的都是最多能启动400个线程。 apache的关键配置如下``` Timeout 180KeepAlive OnMaxKeepAliveRequests 100KeepAliveTimeout 60 StartServers 10ServerLimit 50MaxClients 1500MinSpareThreads 50MaxSpareThreads 200ThreadsPerChild 50MaxRequestsPerChild 10000 ```bash $ cat workers.properties# mod_jk(Apache Tomcat) worker.list=local ```bash worker.local.type=ajp13worker.local.host=localhostworker.local.port=7001worker.local.lbfactor=50worker.local.cachesize=100worker.local.cache_timeout=600worker.local.socket_keepalive=1worker.local.recycle_timeout=300 upstream jboss {server 127.0.0.1:7002;keepalive 10;}server {listen 1080;server_name localhost;charset gbk;proxy_set_header Host $http_host;proxy_set_header X-Forwarded-By $server_addr:$server_port;proxy_set_header X-Forwarded-For $remote_addr;proxy_set_header Connection "";proxy_http_version 1.1;location / {rewrite ^/?$ /index.html permanent;index index.html index.htm;proxy_pass http://jboss;proxy_intercept_errors on;proxy_connect_timeout 5s;proxy_read_timeout 10s;proxy_send_timeout 5s;proxy_buffer_size 16k;proxy_buffers 8 64k;proxy_busy_buffers_size 128k;} 测试的结果表明对于普通的java应用，nginx的延迟会稍微地点，QPS会稍微能跑的高点点。  但是整体来说，性能的瓶颈点还是在后端的java上面，使用nginx的整体性能上提升不大，不过因为nginx使用的非阻塞IO模型，nginx的不会像apache一样因为总体的连接数达到上线而不能处理。后来又单独测试了一下nginx和apache在处理一个普通的静态页面时对比，为了不使得测试的受限制于带宽，页面大小搞了个663字节的，不过最后的结果我觉得还是因为把虚拟机的带宽快跑满了。  nginx的峰值大概时26588.81/s，带宽用了130Mbps左右。从图书可以看出随着并发数的增加nginx的响应时间也有所提升，不过不大，apache的就飙的很夸张了，QPS大幅度下降，延迟飙升特别大。 机器配置：processor : 0model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHzprocessor : 1model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHzprocessor : 2model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHzprocessor : 3model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz $ free -mtotal used free shared buffers cachedMem: 2000 1401 598 0 11 1220-/+ buffers/cache: 169 1830Swap: 1953 4 1948

其实之前http 2.4.1刚出来的时候就很多做对比的了。 大部分分测试表明对于静态文件而已，nginx的性能还是会稍微好些，但是event模式下的httpd比之前的性能是提升得太多太多了。httpd安装起来比较麻烦，尤其是在老掉牙的机器上。 httpd 2.4.4在RHEL 4.8的安装过程大概这样的： 下载最新的httpd 2.4.4解压，然后再下载apr-1.4.6.tar.bz2和apr-util-1.5.1.tar.bz2放到httpd目录下的srclib,解压后把文件夹更名为apr和apr-util.2.安装新版的pcre，我直接在sourceforge.net上下载的.然后编译安装pcre./configure –prefix=/opt/install/pcre-8.32 –enable-pcre32 –enable-jit –enable-utf –enable-pcre16 [sourceforge.net]( http://downloads.sourceforge.net/project/pcre/pcre/8.32/pcre-8.32.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fpcre%2Ffiles%2Fpcre%2F8.32%2F&ts=1362923206&use_mirror=nchc) 3.配置httpd编译./configure –prefix=/opt/install/httpd-2.4.4 –enable-rewrite –enable-cache –enable-ssl –enable-static-ab –enable-ssl –with-included-apr –with-pcre=/opt/install/pcre-8.32/–with-mpm=event 安装好后简单做了一个测试，0.6k的小页面。 nginx 10 25858.43 0.387httpd 10 14952.54 0.669nginx 20 27045.38 0.739httpd 20 14793.54 1.352nginx 30 28513.76 1.052httpd 30 13755.20 2.181nginx 40 26083.62 1.534httpd 40 14023.01 2.852nginx 50 27685.62 1.806httpd 50 14813.10 3.375nginx 60 26779.80 2.240httpd 60 14539.48 4.127nginx 70 26792.31 2.613httpd 70 15989.91 4.378nginx 80 28039.97 2.853httpd 80 16502.71 4.848nginx 90 26900.55 3.346httpd 90 15947.58 5.643nginx 100 38173.08 2.620httpd 100 16635.71 6.011nginx 110 28921.72 3.803httpd 110 16162.35 6.806nginx 120 25804.12 4.650httpd 120 16637.97 7.212nginx 130 26505.68 4.905httpd 130 18882.23 6.885nginx 140 29669.50 4.719httpd 140 19844.80 7.055nginx 150 28969.08 5.178httpd 150 19787.36 7.581nginx 160 27424.76 5.834httpd 160 19325.51 8.279nginx 170 28747.23 5.914httpd 170 21197.41 8.020nginx 180 27160.77 6.627httpd 180 23673.76 7.603nginx 190 27627.75 6.877httpd 190 21609.25 8.793nginx 200 24602.16 8.129httpd 200 21169.24 9.448nginx 210 26838.70 7.825httpd 210 21666.67 9.692nginx 220 31374.85 7.012httpd 220 21994.93 10.002nginx 230 27740.35 8.291httpd 230 22525.72 10.211nginx 240 27235.49 8.812httpd 240 21815.80 11.001nginx 250 26522.97 9.426httpd 250 22031.17 11.348nginx 260 25099.80 10.359httpd 260 22568.75 11.520nginx 270 26291.50 10.269httpd 270 22478.80 12.011nginx 280 25170.07 11.124httpd 280 21437.80 13.061nginx 290 24715.85 11.733httpd 290 21608.02 13.421nginx 300 24808.90 12.092httpd 300 21850.39 13.730nginx 310 27543.54 11.255httpd 310 23166.22 13.382nginx 320 26233.97 12.198httpd 320 23188.51 13.800nginx 330 25436.90 12.973httpd 330 23033.17 14.327nginx 340 26146.07 13.004httpd 340 23096.69 14.721nginx 350 25621.51 13.660httpd 350 23384.09 14.967nginx 360 26820.90 13.422httpd 360 22797.59 15.791nginx 370 25497.89 14.511httpd 370 22911.63 16.149nginx 380 25046.86 15.172httpd 380 22242.29 17.085nginx 390 26514.52 14.709httpd 390 22806.97 17.100nginx 400 24104.89 16.594httpd 400 22924.32 17.449nginx 410 26306.69 15.585httpd 410 22585.88 18.153nginx 420 26518.78 15.838httpd 420 22691.66 18.509nginx 430 27305.07 15.748httpd 430 23292.43 18.461nginx 440 27557.12 15.967httpd 440 22258.63 19.768nginx 450 26536.61 16.958httpd 450 22237.17 20.236nginx 460 25901.85 17.759httpd 460 22664.55 20.296nginx 470 24743.76 18.995httpd 470 22935.42 20.492nginx 480 26813.46 17.901httpd 480 23693.59 20.259nginx 490 25869.61 18.941httpd 490 23374.27 20.963nginx 500 24618.19 20.310httpd 500 22318.36 22.403 从图可以看出httpd 2.4.4在高并发的还是略逊于nginx。 ...

今天看某群里有同学说做ssl卸载的nginx上有很多408错误日志。然后我也看了下我们服务器上果然有好多的，比例还不小，好几个百分点呢。HTTP状态码的还以可以简单参考http://en.wikipedia.org/wiki/List_of_HTTP_status_codes 400 Bad Request The request cannot be fulfilled due to bad syntax 408 Request TimeoutThe server timed out waiting for the request.[2] According to W3 HTTP specifications: “The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.”408错误是由于由于client方在设置的时间内(client_header_timeout和client_body_timeout，nginx下默认都是60s)没有发送完请求造成的。 其实主要是因为现在的浏览器，比如chrome的话在打开页面是会并发开10个左右的请求，其实只有一个是实际会用的，其他的几个请求虽然用不上，但是浏览器也不管，最后会因为达到超时的时间被server短断掉。为此我专门抓包测试了一下。在自己的VPS上开2个窗口，一个用来抓包，另外一个观察日志。抓包的时候过滤一下，只看SYN和FIN包的，然后chrome浏览器里打开自己的blog。tcpdump -i venet0 host 218.109.58.145 and ‘tcp[tcpflags] & (tcp-syn|tcp-fin) !=0 ‘ -ntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes15:05:46.564166 IP 218.109.58.145.63349 > 184.82.227.17.443: Flags [S], seq 1769258416, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.564202 IP 184.82.227.17.443 > 218.109.58.145.63349: Flags [S.], seq 1090238511, ack 1769258417, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.579764 IP 218.109.58.145.63350 > 184.82.227.17.443: Flags [S], seq 2476535492, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.579790 IP 184.82.227.17.443 > 218.109.58.145.63350: Flags [S.], seq 1079878779, ack 2476535493, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.580418 IP 218.109.58.145.63351 > 184.82.227.17.443: Flags [S], seq 3924057720, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.580444 IP 184.82.227.17.443 > 218.109.58.145.63351: Flags [S.], seq 1076802158, ack 3924057721, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.583872 IP 218.109.58.145.63352 > 184.82.227.17.443: Flags [S], seq 1351188747, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.583897 IP 184.82.227.17.443 > 218.109.58.145.63352: Flags [S.], seq 1085259777, ack 1351188748, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.591067 IP 218.109.58.145.63353 > 184.82.227.17.443: Flags [S], seq 3937887977, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.591094 IP 184.82.227.17.443 > 218.109.58.145.63353: Flags [S.], seq 1089841397, ack 3937887978, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.592480 IP 218.109.58.145.63354 > 184.82.227.17.443: Flags [S], seq 1123849790, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.592504 IP 184.82.227.17.443 > 218.109.58.145.63354: Flags [S.], seq 1090612586, ack 1123849791, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.593123 IP 218.109.58.145.63355 > 184.82.227.17.443: Flags [S], seq 4065204445, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.593149 IP 184.82.227.17.443 > 218.109.58.145.63355: Flags [S.], seq 1080746021, ack 4065204446, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:46.831197 IP 218.109.58.145.63357 > 184.82.227.17.443: Flags [S], seq 3474172840, win 8192, options [mss 1452,nop,nop,sackOK], length 015:05:46.831235 IP 184.82.227.17.443 > 218.109.58.145.63357: Flags [S.], seq 1084428126, ack 3474172841, win 5840, options [mss 1460,nop,nop,sackOK], length 015:05:54.366066 IP 184.82.227.17.443 > 218.109.58.145.63349: Flags [F.], seq 22377, ack 810, win 8576, length 015:05:57.138228 IP 218.109.58.145.63357 > 184.82.227.17.443: Flags [F.], seq 1, ack 1, win 17520, length 015:05:57.138506 IP 184.82.227.17.443 > 218.109.58.145.63357: Flags [F.], seq 1, ack 2, win 5840, length 015:05:57.780671 IP 218.109.58.145.63349 > 184.82.227.17.443: Flags [F.], seq 810, ack 22378, win 17483, length 015:06:46.859866 IP 184.82.227.17.443 > 218.109.58.145.63350: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:46.860807 IP 184.82.227.17.443 > 218.109.58.145.63351: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:46.861809 IP 184.82.227.17.443 > 218.109.58.145.63352: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:46.864806 IP 184.82.227.17.443 > 218.109.58.145.63353: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:46.865888 IP 184.82.227.17.443 > 218.109.58.145.63355: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:46.866803 IP 184.82.227.17.443 > 218.109.58.145.63354: Flags [F.], seq 6079, ack 389, win 7504, length 015:06:47.756153 IP 218.109.58.145.63350 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:47.756168 IP 218.109.58.145.63355 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:47.756569 IP 218.109.58.145.63353 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:47.757960 IP 218.109.58.145.63351 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:47.758234 IP 218.109.58.145.63352 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:47.759712 IP 218.109.58.145.63354 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 015:06:48.361787 IP 218.109.58.145.63350 > 184.82.227.17.443: Flags [F.], seq 389, ack 6080, win 17250, length 0 nginx日志里– – 218.109.58.145:63185 – – [10/Mar/2013:15:03:40 +0000] gnuers.org “GET / HTTP/1.1” 200 15929 “-” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17” “-” “unix:/var/run/php5-fpm.sock” 1.449 0.289– – 218.109.58.145:63186 – – [10/Mar/2013:15:03:49 +0000] localhost “-” 400 0 “-” “-” “-” “-” 0.000 –– – 218.109.58.145:63179 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.999 –– – 218.109.58.145:63180 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 60.000 –– – 218.109.58.145:63181 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.991 –– – 218.109.58.145:63182 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.991 –– – 218.109.58.145:63183 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.992 –– – 218.109.58.145:63184 – – [10/Mar/2013:15:04:39 +0000] localhost “-” 408 0 “-” “-” “-” “-” 60.000 –– – 218.109.58.145:63349 – – [10/Mar/2013:15:05:49 +0000] gnuers.org “GET / HTTP/1.1” 200 15929 “-” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17” “-” “unix:/var/run/php5-fpm.sock” 2.525 0.271– – 218.109.58.145:63357 – – [10/Mar/2013:15:05:57 +0000] localhost “-” 400 0 “-” “-” “-” “-” 0.000 –– – 218.109.58.145:63350 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.991 –– – 218.109.58.145:63351 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.987 –– – 218.109.58.145:63352 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.988 –– – 218.109.58.145:63353 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.991 –– – 218.109.58.145:63355 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.992 –– – 218.109.58.145:63354 – – [10/Mar/2013:15:06:46 +0000] localhost “-” 408 0 “-” “-” “-” “-” 59.993 – ...

根据前面blog说的ec2的低级错误造成的重大损失后，马上也想到EC2也快过期了就单独新买一个VPS。今天上午折腾了一下终于把数据都迁移好了。其实迁移blog主要是把db数据备份好。然后图片文件什么都通通打包下来。我是把blog目录直接整体打包了（包括图片什么的）。DB数据的备份就是使用的tools.php?page=wp-db-backup进行的。之前是设置了每周备份发送到邮箱里。昨天马上又保存了一份在自己电脑上面。然后把blog目录直接打个tgz包放到新的机器上面。1.重新配置lnmp环境1.1安装mysqlaptitude install mysql-server mysql-client安装的时候会设置一下mysql的密码，自己记住就行。1.2安装php5-fpmaptitude install php5-fpm php5-mysql nginx-full/etc/php5/fpm/pool.d/www.conf修改user = www-datagroup = www-datalisten.owner = www-datalisten.group = www-datalisten = /var/run/php5-fpm.sock #我是监听的sock形式/etc/init.d/php5-fpm restart 1.3 nginx配置nginx.conf 里面改动比较小，加client_max_body_size 50m;#防止上传文件的时候超过大小keepalive_timeout 5; #把这个减小一点，主要是机器配置也不好。gzip on;#gzip什么的开启节省带宽，也能提高速度gzip_vary on;gzip_proxied any;gzip_comp_level 6;gzip_buffers 16 8k;gzip_http_version 1.1;gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;/etc/nginx/sites-enabled/default 修改的多些,因为我申请了IPV6的地址，所以装B一把也把V6的监听起来。server段先定义一下限流的zonelimit_req_zone $binary_remote_addr zone=gnuers:10m rate=30r/s;listen 80;listen [::]:80 ipv6only=on;location php直接这样改改,加了防止盗链什么的，还限制了访问的host。bash location ~ .php$ {if ( $host !~* blog.gnuers.org ){rewrite ^ https://www.google.com permanent; }fastcgi_split_path_info ^(.+.php)(/.+)$; # NOTE: You should have “cgi.fix_pathinfo = 0; " in php.ini## # With php5-cgi alone:# # With php5-fpm:fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_intercept_errors on; fastcgi_buffers 1024 4k; fastcgi_buffer_size 64k; fastcgi_busy_buffers_size 128k; fastcgi_send_timeout 60; fastcgi_read_timeout 60; fastcgi_connect_timeout 60; }location ~* .(gif|jpg|png|swf|flv)$ {valid_referers none blocked blog.gnuers.org ; if ($invalid_referer) {rewrite ^ http://www.google.com/ permanent; }expires 20m; } 1.3导入DB mysqldump -h localhost -u root -p 输入密码后登陆mysql，create database wordpress; use wordpress; set names utf8; #一定记得加这个，我之前么有加这个直接 mysql -h localhost -u root -pxxxxx wordpress#后中文乱码 source wordpress_wp_backup.sql ; ...

最近在对比apache和nginx放jboss前面的性能。发现我配置的nginx 对后端server不能使用长连接去连。具体的就是抓包吧： tcpdump -i lo port 7002 and ‘tcp[tcpflags] & (tcp-syn|tcp-fin) !=0 ‘ -nn 可以看到每个请求完毕后连接都关闭了。然后抓包搞一晚上，试过N个版本排查了N久，后恰好看文景同学在线就咨询了一下他。我之前的配置文件是： upstream jboss {server 127.0.0.1:7002; keepalive 10; }………….proxy_set_header Connection ""; proxy_http_version 1.1; sendfile on; rewrite ^$ /index.html permanent; location / {index index.html index.htm; proxy_pass http://jboss; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-By $server_addr:$server_port; proxy_set_header X-Forwarded-For $remote_addr; proxy_intercept_errors on; proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 5s; proxy_buffer_size 16k; proxy_buffers 8 64k; proxy_busy_buffers_size 128k; } 文景提醒我说proxy_set_header需要配置在一起才行，试过把 proxy_set_header Connection “”;放到location里面后果然就OK了。当然，也可以把这些都直接放在server段，但是注意不要再在location短去设置httpd头.WIKI上的说明是proxy_set_header directives issued at higher levels are only inherited when no proxy_set_header directives have been issued at a given level. ...

其实早就想申请一个ssl证书，不过觉得有点麻烦就没有搞。今天申请了一下，简单说一下：1. 直接在http://www.startssl.com/上点一下StartSSL Free(Class 1)，把自己的基本资料填写好，提交好后邮箱会马上收到一个验证码。2.收到验证码后需要给自己创建一个证书，直接点几下就行了。最后证书会安装到浏览器内。3.验证域名的所有权然后输入自己的域名，之后会自动查询域名的注册时留下的邮箱，并且会向邮箱发送一个验证码，输入后就可以完成对这个域名的认证了。 4.签发自己的证书后把证书，私钥，证书链和ca都放自己的机器上。nginx下的证书链配置是证书在最前面，然后逐级追加中间ca，最后是把ca加在最后面。 新建一个server段，加配置ssl on;ssl_certificate cert/server.crt;ssl_certificate_key cert/server.key;

nginx做cache其实也比较简单。配置项非常少 #user nobody; worker_processes 1; error_log logs/error.log; pid logs/nginx.pid; events {worker_connections 65535;} http {include mime.types; default_type application/octet-stream; underscores_in_headers on; log_format main ‘$http_orig_client_ip $remote_addr $host – $remote_user [$time_local] "$request" ‘‘$status $body_bytes_sent "$http_referer" ‘‘"$http_user_agent" "$http_x_forwarded_for"’; }} 如果是想把内容放内存，可以把缓存的路径设置到shm里面。

上周结果有客户投诉说不能正常下载账单，之前我以为是nginx的proxy_read_timeout设置引起的。因为我之前错误地把这个理解为nginx从后端读取返回的总时间限制。但是后来对这个参数的说明进行了进一步的查阅，发现不是这么个意思。 [查阅](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)``` Defines a timeout for reading a response from the proxied server. A timeout is only set between two successive readoperations, not for the transmission of the whole response. If a proxied server does not transmit anything within thistime, a connection is closed. 今天晚上回到家后又测试了一下，因为家里的网络非常烂，但是测试了几次都能正常下载。考虑到之前我让同事转告客户那边换个chrome浏览器，但客户那边说无法下载其他浏览器，让我们给QQ传个文件过去，我就猜想对付是不是内部使用代理系统上网的，可能会引发很多这样那样的问题。 只能让对方再试试下载其他文件有没有问题了。如果还有问题肯定是对方内部网络的问题了。

由于代理服务器上开启了长连接后，可以减少每次与后端服务器的三次握手，提高后端服务器的效率。所以nginx在1.1.4版本中终于增加了upstream对keepalive的支持，而haproxy原本对后端是支持长连接的（但是这个时候由于不能把client的IP加到header转发给后端服务器造成会丢失客户端的IP）。今天简单测试了一下。基本的结构是A:Client –> nginx(proxy) –>nginx(server)B:Client –> haproxy(proxy) –>nginx(server) 对比的结构 Client –>nginx(server) 先测试一下client直接和server端能否保持住长连接，我是直接在server端抓包观察，确定OK后再进行nginx和haproxy的测试。 nginx proxy的配置如下： server { location / {root html; proxy_set_header Connection ""; proxy_http_version 1.1; proxy_intercept_errors on; proxy_set_header Host $http_host; proxy_set_header ORIG_CLIENT_IP $remote_addr; index index.html,index.htm; proxy_pass http://httpd; } 0172.189.085.161.50970-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50970: HTTP/1.1 304 Not Modified0172.189.085.161.50971-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50971: HTTP/1.1 404 Not Found0172.189.085.161.50972-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50972: HTTP/1.1 304 Not Modified0172.189.085.161.50973-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50973: HTTP/1.1 404 Not Found0172.189.085.161.50974-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50974: HTTP/1.1 304 Not Modified0172.189.085.161.50975-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50975: HTTP/1.1 404 Not Found0172.189.085.161.50976-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50976: HTTP/1.1 304 Not Modified0172.189.085.161.50977-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50977: HTTP/1.1 404 Not Found0172.189.085.161.50978-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50978: HTTP/1.1 304 Not Modified0172.189.085.161.50979-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50979: HTTP/1.1 404 Not Found0172.189.085.161.50980-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50980: HTTP/1.1 304 Not Modified0172.189.085.161.50981-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50981: HTTP/1.1 404 Not Found0172.189.085.161.50982-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50982: HTTP/1.1 304 Not Modified0172.189.085.161.50983-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50983: HTTP/1.1 404 Not Found0172.189.085.161.50984-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50984: HTTP/1.1 304 Not Modified0172.189.085.161.50985-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50985: HTTP/1.1 404 Not Found0172.189.085.161.50986-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50986: HTTP/1.1 304 Not Modified0172.189.085.161.50987-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50987: HTTP/1.1 404 Not Found0172.189.085.161.50988-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50988: HTTP/1.1 304 Not Modified0172.189.085.161.50989-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50989: HTTP/1.1 404 Not Found0172.189.085.161.50990-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50990: HTTP/1.1 304 Not Modified0172.189.085.161.50991-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50991: HTTP/1.1 404 Not Found0172.189.085.161.50992-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50992: HTTP/1.1 304 Not Modified0172.189.085.161.50993-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50993: HTTP/1.1 404 Not Found0172.189.085.161.50994-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50994: HTTP/1.1 304 Not Modified0172.189.085.161.50995-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50995: HTTP/1.1 404 Not Found0172.189.085.161.50996-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50996: HTTP/1.1 304 Not Modified0172.189.085.161.50997-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50997: HTTP/1.1 404 Not Found server { ```bash location / {root html;proxy_set_header Connection "";proxy_http_version 1.1;proxy_intercept_errors on;proxy_set_header Host $http_host;proxy_set_header ORIG_CLIENT_IP $remote_addr;index index.html,index.htm;proxy_pass http://httpd;} 0172.189.085.161.50998-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 304 Not Modified0172.189.085.161.50998-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 404 Not Found0172.189.085.161.50998-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 304 Not Modified0172.189.085.161.50998-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 404 Not Found0172.189.085.161.50998-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 304 Not Modified0172.189.085.161.50998-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 404 Not Found0172.189.085.161.50998-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 304 Not Modified0172.189.085.161.50998-0172.189.085.156.01080: GET /favicon.ico HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 404 Not Found0172.189.085.161.50998-0172.189.085.156.01080: GET /index.html HTTP/1.10172.189.085.156.01080-0172.189.085.161.50998: HTTP/1.1 304 Not Modified 然后我又测试了一下haproxy。主要是之前对haproxy的理解有点误区。一方面doc里面说了 ```bash A last improvement in the communications is the pipelining mode. It still useskeep-alive, but the client does not wait for the first response to send thesecond request. This is useful for fetching large number of images composing apage : [CON] [REQ1] [REQ2] … [RESP1] [RESP2] [CLO] … ...