腾讯二面，apache中keepalive参数，以及Nginx为什么静态能力强

昨天面了腾讯二面，面试官是一个性格很好的人，没有一面面试官那么严肃，让我挑一个做的好的他来问我。于是本人果断又选择了LVS.面试官问的几个场景都能给出具体的解决方案，我想应该是他比较满意的。
然后，他又问了apache中的keepalive参数以及Nginx为什么是静态处理能力强。没有答上来，在此做个记录。

Apache的KeepAlive参数。

（转载自https://www.cnblogs.com/fnng/archive/2012/11/25/2787755.html，我觉得讲的很清晰透彻，就没又改动。）
KeepAlive的含义                                                                               

　　KeepAlive配置的含义：对于HTTP/1.1的客户端来说，将会尽量的保持客户的HTTP连接，通过一个连接传送多份HTTP请求响应。这样对于客户端来说，可以提高50%左右的响应时间，而于服务器端来说则降低了更多个连接的开销。不过这个依赖于客户端是否想保持连接。IE默认是保持连接的，当你打开100个图片的网站时，IE有可能只打开2个连接，通过这两个连接传送数据，而不是开100个连接。

　　在 Apache 服务器中，KeepAlive 是一个布尔值，On 代表打开，Off 代表关闭，这个指令在其他众多的 HTTPD 服务器中都是存在的。



　　KeepAliveTimeout 为持久连接保持的时间，也就是说，在这此连接结束后开始计时，多长时间内没有重新发送HTTP请求，就断掉连接。默认设置为5秒，这个值可以大点，但不能太大，否则会出现同时等候过多连接，导致多的内存被占用。



KeepAlive的作用                                                                              

如何谋求网络带宽与服务器资源之间的平衡。这个要根据具体情况，具体分析。


那么我们考虑3种情况：
　　1。用户浏览一个网页时，除了网页本身外，还引用了多个 javascript 文件，多个 css 文件，多个图片文件，并且这些文件都在同一个 HTTP 服务器上。
　　2。用户浏览一个网页时，除了网页本身外，还引用一个 javascript 文件，一个图片文件。
　　3。用户浏览的是一个动态网页，由程序即时生成内容，并且不引用其他内容。

　　对于上面3中情况，我认为：1 最适合打开 KeepAlive ，2 随意，3 最适合关闭 KeepAlive

　　
　　在 Apache 中，打开和关闭 KeepAlive 功能，服务器端会有什么异同呢？ 下面看理论分析。

　　打开 KeepAlive 后，意味着每次用户完成全部访问后，都要保持一定时间后才关闭会关闭 TCP 连接，那么在关闭连接之前，必然会有一个Apache 进程对应于该用户而不能处理其他用户，假设 KeepAlive 的超时时间为 10 秒种，服务器每秒处理 50个独立用户访问，那么系统中 Apache 的总进程数就是 10 * 50 ＝ 500 个，如果一个进程占用 4M 内存，那么总共会消耗 2G内存，所以可以看出，在这种配置中，相当消耗内存，但好处是系统只处理了 50次 TCP 的握手和关闭操作。

　　如果关闭 KeepAlive，如果还是每秒50个用户访问，如果用户每次连续的请求数为3个，那么 Apache 的总进程数就是 50 * 3= 150 个，如果还是每个进程占用 4M 内存，那么总的内存消耗为 600M，这种配置能节省大量内存，但是，系统处理了 150 次 TCP的握手和关闭的操作，因此又会多消耗一些 CPU 资源。

　　在看看实践的观察。

　　在一组大量处理动态网页内容的服务器中，起初打开 KeepAlive功能，经常观察到用户访问量大时Apache进程数也非常多，系统频繁使用交换内存，系统不稳定，有时负载会出现较大波动。关闭了 KeepAlive功能后，看到明显的变化是： Apache 的进程数减少了，空闲内存增加了，用于文件系统Cache的内存也增加了，CPU的开销增加了，但是服务更稳定了，系统负载也比较稳定，很少有负载大范围波动的情况，负载有一定程度的降低；变化不明显的是：访问量较少的时候，系统平均负载没有明显变化。

　　总结一下：
　　在内存非常充足的服务器上，不管是否关闭 KeepAlive 功能，服务器性能不会有明显变化；
　　如果服务器内存较少，或者服务器有非常大量的文件系统访问时，或者主要处理动态网页服务，关闭 KeepAlive 后可以节省很多内存，而节省出来的内存用于文件系统Cache，可以提高文件系统访问的性能，并且系统会更加稳定。 

Nginx为何静态处理能力强

因为，Apache所使用的select网络I/O模型十分低效
而Nginx的epoll模型效率会高很多。
首先，我们来定义流的概念，一个流可以是文件，socket等可以进行I/O操作的内核对象。
之后，我们讨论I/O操作，通过read，我们可以从流中读取数据。通过write，我们可以往流中读数据。
现在，我们假设存在一个流，他在内核缓冲区中（缓冲区的引入减少频繁I/O而引起频繁的系统调用。）。
A>>===============>>B
A端为流的入口，B端为流的出口。
B的任务是从流中读取数据，A的任务是往流中写入数据。
若B在读取数据时，发现A并没有向流中写入数据，那么B就会阻塞。
如果我们采用的时“非阻塞忙轮询的I/O”方式，那么，就会存在多个流。我们知道，非阻塞忙轮询下的I/O事件会交给其他对象处理（如select或者epoll）甚至不处理。
所以为了避免他不处理的情况（CPU空转），我们引入了select，他在线程空闲的时候，就将线程阻塞掉。当有一个流或者多个流存在I/O事件时，就将线程唤醒。然后就去处理。
然而，这还会带来一个问题。就是select只能告诉我们又I/O事件发生了，但是，它并不能告诉我们是哪个流发生了I/O事件。因此我们需要再次全部轮询，以查找。
而epoll此时诞生了，它可以告诉我们是哪个流发生了怎样的I/O事件，从而可以节省许多时间。

一个是挨家挨户敲门去查找复杂度为O(n)，一个是直接按编号查找复杂度为O（1）。