0opslab

Nginx的主要可以从如下几个方面入手：

  • 升级服务器配置，比如上SSD硬盘，升级带宽
  • 根据业务优化服务器的内核参数
  • 根据业务优化Nginx的配置
  • 优化后台服务

升级服务器配置

SSD硬盘是一个快速存储装置，没有即系运动部件，因此其访问速度相对机械硬盘是无延迟的，另外其几乎无热量产生，更加省电，因此直接上SSD硬盘是相当划算的选择。这比做很多优化配置来的更加直接。

优化服务器内核参数

以下操作除非你知道你在做什么，否则请勿乱修改。

// 查看各个状态的网络连接请求数
$ netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'

// 调整同时打开文件的数量
ulimit -n 20480

// linux的/etc/sysctl.conf 更改内核参数,并使用sysctl -p命令使配置立即生效
// 表示单个进场最大可以打开的句柄书
fs.file-max = 999999
// 允许将TIME_WAIT状态的socket重新用于新的TCP连接
net.ipv4.tcp_tw_reuse = 1
// 当keepalive启动时,TCP发送keepalive消息的频度，单位为秒,设置的更新能加快清理无效的连接
net.ipv4.tcp_keepalive_time = 600
// 当服务器主动关闭链接时，socket保持在FIN_WAIT_2状态的最大时间
net.ipv4.tcp_fin_timeout = 30 

// 这个参数表示操作系统允许TIME_WAIT套接字数量的最大值，如果超过这个数字，
//TIME_WAIT套接字将立刻被清除并打印警告信息。该值不能过大
net.ipv4.tcp_max_tw_buckets = 5000

// 定义UDP和TCP连接的本地端口的取值范围
net.ipv4.ip_local_port_range = 1024 65000 

//定义了TCP接受缓存的最小值、默认值、最大值
net.ipv4.tcp_rmem = 10240 87380 12582912

//定义TCP发送缓存的最小值、默认值、最大值。
net.ipv4.tcp_wmem = 10240 87380 12582912

//当网卡接收数据包的速度大于内核处理速度时，会有一个列队保存这些数据包。这个参数表示该列队的最大值
net.core.netdev_max_backlog = 8096 

// 表示内核套接字接受缓存区默认大小
net.core.rmem_default = 6291456

//表示内核套接字发送缓存区默认大小
net.core.wmem_default = 6291456  

//表示内核套接字接受缓存区最大大小。
net.core.rmem_max = 12582912

//表示内核套接字发送缓存区最大大小
net.core.wmem_max = 12582912

//与性能无关。用于解决TCP的SYN攻击。
net.ipv4.tcp_syncookies = 1

//这个参数表示TCP三次握手建立阶段接受SYN请求列队的最大长度，默认1024，
//将其设置的大一些可以使出现Nginx繁忙来不及accept新连接的情况时，Linux不至于丢失客户端发起的链接请求。
net.ipv4.tcp_max_syn_backlog = 262144

//这个参数用于设置启用timewait快速回收
net.ipv4.tcp_tw_recycle = 1

// 选项默认值是128，这个参数用于调节系统同时发起的TCP连接数，在高并发的请求中，
// 默认的值可能会导致链接超时或者重传，因此需要结合高并发请求数来调节此值。
net.core.somaxconn=262114 


//选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。
//如果超过这个数字，孤立链接将立即被复位并输出警告信息。
net.ipv4.tcp_max_orphans=262114 


//关于具体的内核参数请查阅相关的系统 可以使用sysctl -a显示当前全部的参数

nginx的性能是没的说，但是如果真的除了问题，那肯定是你配置的问题，例如keepalive_timeout 设置的不合理，日志记录过多或者未使用缓存等等，另外就是是后台的问题。建议开启request_time和upstream_response_time，将这俩个值写入到access日志中。

request_time 指的就是从接受用户请求的第一个字节到发送完响应数据的时间，即包括接收请求数据时间、程序响应时间、输出响应数据时间。

upstream_response_time 是指从Nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间。

将上述俩个值记录到access日志文本中，然后通过统计分析将需要优化的后台接口交给开发人员进行优化，如果像我这种啥活都干的人，只能自己默默的干了。

如下设置Nginx的日志格式,等运行一段时间后分析request_time和upstream_response_time字段，然后优化后台。

 log_format  accesslog  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $request_time $body_bytes_sent $upstream_status ' 
                      '$upstream_addr $upstream_response_time "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '"$http_CFBundleShortVersionString"';

后台系统优化，只能具体的问题具体分析了，如是Java可以用bstrace分析监控JVM等等，如果是PHP可以使用xhprof等工具分析。

至此身为一个Web开发人员，算是入门了Nginx，能使之更加方便和高效的工作了。