Web服务器

Nginx

查找nginx日志耗时接口

2019:11:28 为匹配时间

grep 2019:11:28 /var/log/nginx/*.log | awk '{gsub("\?.*$","",$7);t[$7]+=$12}END{for(i in t) print i,t[i]}' | sort -k2 -nr |head -10

Apache | Tomcat | Haproxy

Web服务器模型

多进程模型的优缺点

优点

  1. 每个进程互相独立，不影响主程序的稳定性，子进程崩溃没关系。

  2. 通过增加CPU，就可以容易扩充性能。

  3. 可以尽量减少线程加锁/解锁的影响，极大提高性能，就算是线程运行的模块算法效率低也没关系。

  4. 每个子进程都有2GB地址空间和相关资源，总体能够达到的性能上限非常大。

缺点

  1. 逻辑控制复杂，需要和主程序交互。

  2. 需要跨进程边界，如果有大数据量传送，就不太好，适合小数据量传送、密集运算。

  3. 多进程调度开销比较大。

多线程模型的优缺点

优点

  1. 无需跨进程边界。

  2. 程序逻辑和控制方式简单。

  3. 所有线程可以直接共享内存和变量等。

  4. 线程方式消耗的总资源比进程方式好。

缺点

  1. 每个线程与主程序共用地址空间，受限于2GB地址空间。

  2. 线程之间的同步和加锁控制比较麻烦。

  3. 一个线程的崩溃可能影响到整个程序的稳定性。

  4. 到达一定的线程数程度后，即使再增加CPU也无法提高性能。

  5. 线程能够提高的总性能有限，而且线程多了之后，线程本身的调度也是一个麻烦事儿，需要消耗较多的CPU 。

如何减少上下文切换

线程池的关键点是：

  1. 尽量减少线程切换和管理的开支。

  2. 最大化利用cpu。

对于第一点，要求线程数尽量少，这样可以减少线程切换和管理的开支。对于第二点，要求尽量多的线程，以保证CPU资源最大化的利用。 所以：

  1. 对于任务耗时短的情况，要求线程尽量少，如果线程太多，有可能出现线程切换和管理的时间，大于任务执行的时间，那效率就低了。

  2. 对于耗时长的任务，要分是cpu任务，还是io等类型的任务。如果是cpu类型的任务，线程数不宜太多；但是如果是io类型的任务，线程多一些更好，可以更充分利用cpu。

所以高并发，低耗时的情况：建议少线程，只要满足并发即可。例如并发100，线程池可能设置为10就可以。低并发，高耗时的情况：建议多线程，保证有空闲线程，接受新的任务。例如并发10，线程池可能就要设置为20。高并发高耗时：1要分析任务类型，2增加排队，3、加大线程数。

I/O多路复用的优缺点

优点

  1. 相比于多线程和多进程，I/O多路复用是在单一进程的上下文中的，当有多个并发连接请求时，多线程或者多进程模型需要为每个连接创建一个线程或者进程，而这些进程或者线程中大部分是被阻塞起来的。由于CPU的核数一般都不大，比如4个核要跑1000个线程，那么每个线程的时间槽非常短，而线程切换非常频繁。这样是有问题的。而使用I/O多路复用时，处理多个连接只需要1个线程监控就绪状态，对就绪的每个连接开一个线程处理（由线程池支持）就可以了，这样需要的线程数大大减少，减少了内存开销和上下文切换的CPU开销。

  2. 整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动。

缺点

  1. 单线程模型不能有阻塞，一旦发生任何阻塞（包括计算机计算延迟）都会使得这个模型不如多线程。另外，单线程模型不能很好的利用多核cpu。

三种I/O多路复用方式介绍（参考这里）

select的优缺点
优点

  1. select的可移植性好，在某些unix下不支持poll.

  2. select对超时值提供了很好的精度，精确到微秒，而poll式毫秒。

缺点

  1. 单个进程可监视的fd数量被限制，默认是1024。

  2. 需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。

  3. 对fd进行扫描时是线性扫描，fd剧增后，IO效率降低，每次调用都对fd进行线性扫描遍历，随着fd的增加会造成遍历速度慢的问题。

  4. select函数超时参数在返回时也是未定义的，考虑到可移植性，每次超时之后进入下一个select之前都要重新设置超时参数。

poll的优缺点
优点

  1. 不要求计算最大文件描述符+1的大小。

  2. 应付大数量的文件描述符时比select要快。

  3. 没有最大连接数的限制是基于链表存储的。

缺点

  1. 大量的fd数组被整体复制于内核态和用户态之间，而不管这样的复制是不是有意义。

  2. 同select相同的是调用结束后需要轮询来获取就绪描述符。

epoll的优缺点（epoll详解）
  1. 支持一个进程打开大数目的socket描述符(FD)

select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完 美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

  1. IO效率不随FD数目增加而线性下降

传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是”活跃”的， 但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对”活跃”的socket进行 操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有”活跃”的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个”伪”AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

参考：

https://blog.csdn.net/wan_hust/article/details/38441455

https://blog.csdn.net/jyy305/article/details/73012706

最近更新：:
Contributors: luokaiwen