web单机优化

又得开始写博客了，目测又要一周一篇了，固然了这不算python跟前端的，我的喜欢notepad++惋惜不能放图片，word什么的太讨厌了

 

为何要单机优化呢，很简单，由于不论之后是各种集群也好，物理机虚拟机也好，只有将我的优点发挥到最大才能提高总体的最低限度，由于木桶原理嘛；再一个，穷啊，玩linux那就是得优化，极尽的压榨操做系统的性能。集群什么的都是从单机演化出来的，so，优化好单机是你继续下一步的初始条件

 

咱们从一个请求链接的总流程来看一下咱们可优化的点（运维角度）

 

 

 

其实这中间的每个步骤速度提高都对咱们的性能有提高（此时的性能是指用户的客观感觉，就是开你网页快不快），每次网站变卡了，领导就说去赶快加点带宽去，这句话也是对的，带宽大了，数据发送的时间就会变少，加带宽确定是对性能提高有好处的，so如今知道了大家老大其实也是很专业的了吧~~~

好了，不卖萌了，做为专业的运维，咱们确定是但愿花合适的时间金钱在最合适的提高位置，这也就是所谓的 “瓶颈点”，所以作优化，找出“瓶颈点”最为关键！可是很是惋惜咱们只能从本身的服务器这面进行优化的进行，由于找出“瓶颈点”这就是一个很现实的事情了，纸上谈兵，毫无心义。

 

所以，进入今天的主题吧，单机web性能优化！

彻底单机的web实际上是不容易针对优化的，由于全部的服务都须要安放在一台机器上，常见的就是咱们喜欢的lnmp，一台电脑上要装nginx、php、mysql，可能还有一些其余的什么鬼，so，我萌只能进行一些通用的优化了。

 

一.从系统自己限制考虑

先从咱们的服务器自己考虑，咱们须要使用ulimit 这个熟悉的命令将每一个进程能够打开的文件数目加大到65535（默认值1024）并更改系统可打开的总文件数目，为何要改这玩意？because on Linux everything is file，so，we must do it！仍是不理解，好吧，每当建立一个链接后，这让条链接都会打开若干文件，哪怕至少咱们也要打开一个小socket，这样就会占用一个文件，若是链接过多，而单个任务上有限制只容许一共打开1024个文件，那么后面的链接就进不来了。同理，若是全部任务打开的文件数超过了系统自己容许的上限也不行，因此file-max也是尤其重要的，二者缺一不可！

1 [root@master ~]# ulimit -n
2 1024
3 [root@master ~]# ulimit -n 65535
4 [root@master ~]# ulimit -n
5 65535
6 [root@master ~]# cat /proc/sys/fs/file-max
7 181795
8 [root@master ~]# echo "fs.file-max = 6553560" >>/etc/sysctl.conf

二. 提供的服务类型考虑

咱们对外提供web服务，那么我走的确定是http/https链接了，对内我本身的业务须要链接本身的数据库，，so，总的来讲我走的就是tcp链接，既然如此咱们先回顾下经典的三握四挥吧

 

 

流程及三次握手相关的就不说了就那么几下，直接总结挥手重要的

time_wait出如今客户端主动断开链接后

close_wait出如今服务端主动断开链接后

其实time_wait是不太好，并且他在断开后仍是会留有一个2分钟的文件，这样就占用了上面的可打开文件数资源！so，咱们从这一点进行相关优化，首先，咱们要思考下为何链接断开了，默认仍是会保留状态呢，写tcp协议这哥们是否是傻，是否是傻，你以为他是否是傻？其实不是，人家只是基于当时的环境考虑了一些问题：

1. 防止上一次链接的包在网络传输中迷路了，要把它收回来
2. TCP不是UDP，要保证可靠性！在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会从新发fin, 若是这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。因此主动方要处于 TIME_WAIT 状态，而不能是 CLOSED！
3. 另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短期内接受大量请求或者受到攻击

固然，这是基于当年的网络环境下的考虑，1981年的网络情况大约4分钟你传输一个byte！so不解释了（我怎么知道的？由于我会穿越时空啊，我刚才还去买了几瓶82年的雪碧呢~），可是这不是咱们就不优化的理由呀，so，咱们有三个内核参数来解决这个问题。

 

1. tcp_tw_reuse复用，毕竟每次建立TCP链接是须要消耗资源的，若是TIME-WAIT sockets能复用那真的很不错，咱们能够在任何地方开启它
2. tcp_tw_recycle快速销魂，它在内网环境下会很给力，可让你快速回收TIME_WAIT sockets，可是它有一个问题就是不能够在NAT负载均衡器上打开
3. tcp_timestamps是上面两个选项的基础条件，不过默认状况下是已经打开的，它就是在打一个时间戳，咱们须要一个标识来肯定sockets是否该被回收或是复用

 

1 [root@master ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse
2 0
3 [root@master ~]# cat /proc/sys/net/ipv4/tcp_timestamps
4 1
5 [root@master ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle
6 0
7 [root@master ~]# echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
8 [root@master ~]# echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

再从最简单的方面考虑下，咱们不就是以为TIME_WAIT 的时间太长了么，那么咱们把它直接改小不就能够了么，改过小也很差，会引发其余问题

1 [root@master ~]# echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout

文件限制方面的优化如今貌似这样就很不错哦，如今咱们不考虑这面单纯的就是想提升该web的并发量，怎么破，咱们都知道创建链接后是两台机器端口间的互相伤害，so，若是咱们能够多开一些端口，有人会问，多开端口那是客户端的问题，你服务端开个80别人连你不都走这个么，这就是架构的魅力所在，在你是服务器的同时，你又是客户端，你提供web就单纯是个html么，不须要交互数据库嘛，不须要拿静态资源嘛，静态资源可能也有个服务器，so，任重而道远啊，多有一些可打开的端口是一件美好的事情了吧

1 [root@master ~]# cat /proc/sys/net/ipv4/ip_local_port_range 
2 32768    60999
3 [root@master ~]# echo "10000 65530" > /proc/sys/net/ipv4/ip_local_port_range

三.组件分离

当服务彻底都在一台机器上时，咱们确定会随着业务量的增多进行分离，通常会先将数据库分离，而后再将静态资源分离。

一会儿整齐了许多，咱们有了3台服务器，在购买服务器的时候咱们就能够针对业务挑选性价比更高的服务器，咱们的应用服务器不须要存储什么东西，so磁盘什么的就能够从简，数据库那必须ssd了，如今已经很便宜了，对io的提高是极其明显的，而文件服务器，用ssd也好，可是cpu跟内存就不须要太关注了。

当咱们的机器分离出来后，已经给咱们的并发量带来了提高，每一个服务都是要占文件描述符的，如今分离出来，各自占本机的，没人跟你抢，还有可以使用的端口。

咱们先优化数据库跟文件服务器，他们都须要对磁盘进行大量的io操做，因此咱们要对磁盘调度方式进行调整，linuxIO调度你们都知道的，基本知识

Cfq：彻底公平，默认选项

Noop:什么都不作，ssd就用这个

Deadline:有一个最后期限，数据库经常使用

So，很明显咱们的文件服务器在使用了ssd盘后就能够将其的盘符的调度改为Noop了，而web服务器可能就是记录下日志，因此使用默认的Cfq就好。而数据库服务器使用Deadline，那么请问使用了ssd的数据库改用Deadline仍是Noop？答案其实都是能够的，其实这二者之间性能差异不大，可是因为数据库的性质，设置一个最后期限仍是更加合理。

最后咱们优化咱们的web服务器，以nginx为例，

高级配置：

worker_processes auto;

Events配置：

use epoll;

worker_connections 65535

HTTP配置：

sendfile on;

tcp_nopush on;

tcp_nodelay on;

前几个就不说了，tcp_nopush与tcp_nodelay的意义是相对的，可是在开启sendfile的状况下并不冲突，简单的说最终的效果就是会将发送的数据一直积累到最大报文长度后再发送，若是是最后的包那么会直接发送不等待。这里面牵扯tcp协议里的东西

 Nagle算法是指知足最大报文长度状况下，马上发送，不然放在缓冲区，减小网络中包的数量提高性能

DelayedAcknowledgment再也不针对单个包发送ACK，而是一次确认两个包，或者在发送响应数据的同时捎带着发送ACK，又或者触发超时时间后再发送ACK，经过减小网络中的ack数量提高网络环境

可是长链接出现奇数包+结束小包时，就会对前两个包很快的进行正常处理，可是第三个包的ack并未返回而是被先缓存起来了，而发送端须要确认此包的ack才能发结束小包结束所有链接，so，须要延迟40ms过时时间才会发送，而后结束链接，从而下降了性能。

在短链接中不会出现这种状况，由于链接是读---写---读---写，马上结束的，由于马上结束了链接，so最后的包是马上发出的