打开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，可以提高文件系统会见的机能，而且系统会越发不变。
ü 增补1
关于是否应该封锁 KeepAlive 选项，我以为可以基于下面的一个公式来判定。
在抱负的网络毗连状况下，系统的Apache 历程数和内存利用可以用如下公式表达：
HttpdProcessNumber= KeepAliveTimeout * TotalRequestPerSecond / Average(KeepAliveRequests)
HttpdUsedMemory= HttpdProcessNumber * MemoryPerHttpdProcess
换成中文意思：
总Apache历程数 = KeepAliveTimeout * 每秒种HTTP请求数 / 平均KeepAlive请求
Apache占用内存 = 总Apache历程数 * 平均每历程占用内存数
需要出格说明的是：
[平均KeepAlive请求] 数，是指每个用户毗连上处事器后，一连发出的 HTTP 请求数。当 KeepAliveTimeout 等 0可能 KeepAlive 封锁时，KeepAliveTimeout 不参加乘的运算从上面的公式看，假如 [每秒用户请求]多，[KeepAliveTimeout] 的值大，[平均KeepAlive请求] 的值小，城市造成 [Apache历程数] 多和 [内存]多，可是当 [平均KeepAlive请求] 的值越大时，[Apache历程数] 和 [内存] 都是趋向于淘汰的。
基于上面的公式，我们就可以推算出当 平均KeepAlive请求 <= KeepAliveTimeout 时，封锁 KeepAlive 选项是划算的，不然就可以思量打开。
ü 增补2
KeepAlive 该参数节制Apache是否答允在一个毗连中有多个请求，默认打开。但对付大大都论坛范例站点来说，凡是配置为off以封锁该支持。
ü 增补3
假如处事器前跑有应用squid处事，可能其它七层设备,KeepAlive On 设定要开启一连长毗连
实际在 前端有squid 的环境下,KeepAlive 很要害。记得On。
Keeyalive不能随心所欲配置，而是需要按照实际环境，我们来看一个真实的在我事情中产生的搞笑一次事件：
其时我已经分开该项目了，该项目标TeamLeader看到了keepalive的观念，他只看到了封锁keeyalive可以节减web处事器的内存，其时我们的web处事器只有4gb内存，而并发请求的量很大，因此他就把这个keepalive设成了off。
然后直接导致脱机客户端（脱机客户端用的是.net然后webservice毗连）的“login”每次都显示“堕落”。