uginx如何提高服务性能？

目录

• 常用命令
• nginx并发优化思路
• nginx gzip 压缩提升网站的速度
• nginx缓存提升网站负载
• nginx实现负载均衡

常用命令

netstat -lpnt  #  列出端口占用情况
kill -9 PID  # 表示杀死进程编号为PID的这个进程
killall -9 服务名  # 表示杀死该服务的所有进程
killall -9 httpd  # 博爱是杀死httpd服务的所有进程
pkill 选项-9 加终端号， 表示踢出该终端
pkill -9 pts/0  # 表示踢出我的远程登录pts、0
./sbin/nginx/ -s reload  # 重启nginx
tail logs/error.log # 查看nginx的错误日志 nginx自带的错误日志文件

ulimit -n  # 查看能够打开的描述符数 默认是1024个描述符  ulimit是操作系统层面的
ulimit -n 20000 # 设置描述符数
./bin/ab -c 2000 -n 80000 http://192.168.1.202/index.html  #两千个并发，八万个请求   测试时请求失败率相当高，而且使用统计模块实际显示的并发数不到1000，与实际开2000个并发不符合
    
more /proc/sys/net/core/somaxconn # 查看Linux操作系统最大连接数 默认128
echo 50000 >/proc/sys/net/core/somaxconn  # 修改Linux操作系统最大连接数为50000
cat /proc/sys/net/ipv4/tcp_tw_recycle  # 查看系统是回收TCP 默认0 不回收
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle  # 修改为1 快速回收

cat /proc/sys/net/ipv4/tcp_tw_reuse # 查看系统是否回收利用TCP 默认0 不回收利用
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse  #  修改为1 回收利用
more /proc/sys/net/ipv4/tcp_syncookies  # 默认为1 阻止洪水抵御
echo 0 > /proc/sys/net/ipv4/tcp_syncookies # 修改为0 不做洪水抵御

nginx并发优化思路

nginx在测试高并发时，当并发数调到2000，发送50000个请求时。报错：“说我们打开的文件太多了”，，其实不是打开文件太多，是每来一个连请求都要建立一个socket连接，在Linux看来就是把网卡看做一个文件，请求一次，打开一个文件，2000个请求打开两千次，因此报打开的文件太多了

# 1.nginx并发优化思路
nginx响应请求：
	1）建立socket连接  # socket连接能不能建那么多？
    2） 打开文件，并沿socket返回  #  内存够不够大？需要内存维护这些信息 然后操作系统是否允许你打开这么多文件？ 默认情况下一个进程允许打开1024个文件

# 2.排查问题
    1）查看系统的dmesg  # possible SYN flooding on port 80. Cookies 洪水攻击
    2）nginx的error.log  # Too many open file
    
# 3.解决问题：
socket:
    nginx层面：每个子进程允许打开的连接（worker_connections）  # 在nginx配置文件修改 10240
    系统层面：
           1) 最大连接数 somaxconn  # 默认128 
           2) 加快tcp连接的回收 recycle
           3) 空的tcp是否允许回收利用 reuse 
           4) 洪水攻击  # 不做洪水抵御 
           5) http连接快速关闭，keep_alivetime:0 # 高并发网站中将nginx的keepalive_tiemout参数设置为0，浏览器响应头中的Connection:keep_alive变为为close，在每次请求网站主页时就不会保持存活再去加载主页上的其他文件（js,css,图片等资源）以使tcp连接使用完快速断开，加速TCP的回收
文件：
	nginx层面：
    	1）一个子进程允许打开的文件  worker_limit_nofile # 在nginx配置文件中修改  worker_limit_nofile 10000;
    系统层面：
    	1） ulimit -n 20000 修改打开文件数  # 设置一个比较大的值
        
 测试结果：
	按照以上的设置，100000（十万）个请求，2000（两千）个并发：
    	./bin/ab -c 2000 -n 100000 https://192.168.1.202/index.html
         
        请求的并发数始终能够保持在2000左右，十万次请求没有失败的请求，98%的请求都在345ms以内完成

nginx gzip 压缩提升网站的速度

原理：浏览器--请求--->声明可以接收gzip压缩或deflate压缩或sdch压缩从http协议的角度看--请求头声明accept-encodig:gzip deflate sdch （是指压缩算法，其中sdch是Google倡导的一种压缩方式，目前支持的服务器尚不多）
服务器--->回应---把内容用gzip方式压缩---->发给浏览器
浏览<----解码gzip----接收gzip压缩内容

注意：图片/MP3这样的二进制文件，不必压缩。因为压缩比较小，比如100->80字节，而且压缩也是耗费CPU资源的

gzip 配置的常用参数
gzip on/off; # 是否开启gzip
gzip_buffers 324K|168K # 缓冲（压缩在内存中缓冲几K？每K多大？）
gzip_comp_level [1-9] # 推荐6 压缩级别（级别越高，压得越小，越浪费CPU计算资源）
gzip_disable # 正则匹配UA 什么样的Uri不进行gzip
gzip_min_length 200 # 开始压缩的最小长度（再小就不要压缩了，意义不大）
gzip_http_version 1.0|1.1  # 开始压缩的http协议版本（可以不设置，目前几乎全是1.1协议）
gzip_proxied  # 如果请求者是代理服务器，该如何缓存内容
gzip_types text/plain,application/xml  # 对那些类型的文件你用压缩 如txt，xml,html,css 
gzip_vary on/off  # 是否传输gzip压缩标志

# nginx.conf 文件编写  将内容写到监听80的server里面
server {
    listen 81;
    server_name localhost;
    gzip on;
    gzip_buffers 324K;
    gzip_com_level 6;  # 一般设置为6就够了
    gzip_min_length 200；
    gzip_type text/css text/xml application/x-javascript;  # 要压缩的文件有css、xml、 javascript
    root html;
}

nginx缓存提升网站负载

对于网站的图片，尤其是新闻站，图片一旦发布，改动的可能是非常小的，我们希望能否在用户访问一次后，图片缓存在用户的浏览器端，且时间比较长的缓存。可以用到nginx的expires设置。nginx中设置过期时间，非常简单，在location或if段里，来写。格式：
	expires 30s;
    expires 30m;
    expires 2h;
    expires 30d;
    
另：304，也是一种很好的缓存手段
原理是：服务器响应文件内容是，同时响应etag标签（内容的签名，内容一变，他也变），和last_modified_since 2个标签值。
浏览器下次去请求时，头信息发送这两个标签，服务器检测文件有没有发生变化，如无，直接头信息返回etag,last_modified_since，浏览器知道内容无改变，于是直接调用本地缓存。这个过程，也请求了服务器，但是传着的内容极少。
    

nginx实现负载均衡

反向代理后端如果有多台服务器，自然可以形成负载均衡，但是proxy_pass 如何指向多台服务器呢？
把多台服务器用up_stream指定绑定在一起并起个组名，然后proxy_pass指向该组；
默认的均衡的算法很简单，就是针对后端服务器的顺序，逐个请求；也有其他负载均衡算法，如一致性哈希，需要安装第三方模块（ngx_http_upstram_consistent_hash）。


server {
    listen 81;
    server_name localhost;
    root html/image;
    access_log logs/81_access.log main;
}
server {
    listen 82;
    server_name localhost;
    root html/image;
    access_log logs/82_access.log main;
}
# 根据权重做负载均衡，权重越大，分配的请求数越多
# weight 权重  max_fails连接多少次之后没连上表示失败 fail_timeout 多少秒连接不上连接超时
up_strem imgsetver {
    server http://192.168.1.200:81 weight=1 max_fails=2 fail_timeout=3
    server http://192.168.1.200:82 weight=1 max_fails=2 fail_timeout=3
}

location ~* \.(jpg|jpeg|gif|png) {
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://imgserver;  # 上面定义了imgserver,凡是遇到图片的请求自动传给imgserver,但imgserver有两个，这里我们不必担心，nginx内部有个机制会做负载均衡
}

location ~* \.py$ {
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://192.168.1.200:8000
}

动静分离配置：https://www.cnblogs.com/jeancheng/p/13038949.html

nginx使用的基本原理1：https://zhuanlan.zhihu.com/p/101961241
nginx使用的基本原理2：https://zhuanlan.zhihu.com/p/102528726