三、 节约Web服务端的内存
前端的优化完成，我们就需要着眼于Web服务端本身。内存是Web服务器非常重要的资源，更多的内存通常意味着可以同时放入更多的工作任务。就Web服务占用内存而言，可以粗略划分：
（1）用来维持连接的基本内存，进程初始化时，会载入一些基础模块到内存。
（2）被传输的数据内容载入到各个缓冲区，占据的内存。
（3）程序执行过程中，申请和使用的内存。
如果维持一个连接，能够尽可能少占用内存，那么我们就可以维持更多的并发连接，从而让Web服务器支持更多的并发连接数。
Apache（httpd）是一个成熟并且古老的Web服务，而Apache的发展和演变，一直在追求做到这一点，它试图不断减少服务占据的内存，以支持更大的并发量。以Apache的工作模式的演变为视角，我们一起来看看，它们是如何优化内存的问题的。
1. prefork MPM，多进程工作模式prefork是Apache最成熟和稳定的工作模式，即使是现在，仍然被广泛使用。主进程生成后，它先完成基础的初始化工作，然后，通过fork预先产生一批的子进程（子进程会复制父进程的内存空间，不需要再做基础的初始化工作）。然后等待服务，之所以预先生成，是为了减少频繁创建和销毁进程的开销。多进程的好处，是进程之间的内存数据不会相互干扰，同时，某个进程异常终止也不会影响其他进程。但是，就内存而言，每个httpd子进程占用了很多的内存，因为子进程的内存数据是复制父进程的。我们可以粗略认为，这里存在大量的“重复数据”被放在内存中。最终，导致我们能够生成的子进程最大数量是很有限。在面对高并发时，因为有不少Keep-alive的长连接，将这些子进程“霸占”住，很可能导致可用子进程耗尽。因此，prefork并不太适合高并发场景。
优点：成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。（例如，我们常用的mod_php，将PHP编译为Apache的子模块，就不需要支持线程安全）
缺点：一个服务进程占用很多内存。
2. worker MPM，多进程和多线程的混合模式worker模式比起prefork，是使用了多进程和多线程的混合模式。它也预先fork了几个子进程（数量很少），然后每个子进程创建一些线程（其中包括一个监听线程）。每个请求过来，会被分配到1个线程来服务。线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，因为比起prefork更省内存，因此会有更多的可用线程。
但是，它并没有解决Keep-alive的长连接“霸占”线程的问题，只是对象变成了比较轻量的线程。
有些人会觉得奇怪，那么这里为什么不完全使用多线程呢，还要引入多进程？因为还需要考虑稳定性，如果一个线程挂了，会导致同一个进程下其他正常的子线程都挂了。如果全部采用多线程，某个线程挂掉，就导致整个Apache服务“全军覆没”。而目前的工作模式，受影响的只是Apache的一部分服务，而不是整个服务。
线程共享父进程的内存空间，减少了内存的占用，却又引起了新的问题。就是“线程安全”，多个线程修改共享资源导致的“竞争行为”，又强迫我们所使用的模块必须支持“线程安全”。因此，它有一定程度上增加Web服务的不稳定性。例如，mod_php所使用的PHP拓展，也同样需要支持“线程安全”，否则，不能在该模式下使用。
优点：占据更少的内存，高并发下表现更优秀。
缺点：必须考虑线程安全的问题，同时锁的引入又增加了CPU的开销。
3. event MPM，多进程和多线程的混合模式，引入Epoll这个是Apache中比较新的模式，在现在的版本（Apache 2.4.10）已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keep-alive场景下，长期被占用的线程的资源浪费问题。event MPM中，会有一个专门的线程来管理这些keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。它减少了“占据”连接而又不使用的资源浪费，增强了高并发场景下的请求处理能力。因为减少了“闲等”的线程，线程的数量减少，同等场景下，内存占用会下降一些。
event MPM在遇到某些不兼容的模块时，会失效，将会回退到worker模式，一个工作线程处理一个请求。新版Apache官方自带的模块，全部是支持event MPM的。注意一点，event MPM需要Linux系统（Linux 2.6+）对EPoll的支持，才能启用。Apache的三种模式中在真实应用场景中，event MPM是最节约内存的。
4. 使用比较轻量的Nginx作为Web服务器虽然Apache的不断优化，减少了内存占用，从而增加了处理高并发的能力。但是，正如前面所说，Apache是一个古老而成熟的Web服务，同时，集成很多稳定的模块，是一个比较重的Web服务。Nginx是个比较轻量的Web服务，占据的内存天然就少于Apache。而且，Nginx通过一个进程来服务于N个连接。所使用的方式，并不是Apache的增加进程/线程来支持更多的连接。对于Nginx来说，它少创建了大量的进程/线程，减少了很多内存的开销。
静态文件的QPS性能压测结果，Nginx性能大概3倍于Apache对静态文件的处理。PHP等动态文件的QPS，Nginx的做法通常是通过FastCGI的方式和PHP-FPM通信的方式完成，PHP作为一个与之无关的外部服务存在。而Apache通常将PHP编译为自己的子模块（新版的Apache也支持FastCGI）。PHP动态文件，Nginx的表现略逊于Apache。
5. sendfile节约内存Apache、Nginx等不少Web服务，都带有sendfile支持的。sendfile可以减少数据到“用户态内存空间”（用户缓冲区）的拷贝，进而减少内存的占用。当然，很多同学第一个反应当然是问Why？为了尽可能清楚讲述这个原理，我们就先回Linux内核态和用户态的存储空间的交互。
一般情况下，用户态（也就是我们的程序所在的内存空间）是不会直接读写或者操作各种设备（磁盘、网络、终端等），中间通常用内核作为“中间人”，来完成对设备的操作或者读写。
以最简单的磁盘读写例子，从磁盘中读取A文件，写入到B文件。A文件数据是从磁盘开始，然后载入到“内核缓冲区”，然后再拷贝到“用户缓冲区”，我们才可以对数据进行处理。写入的时候，也同理，从“用户态缓冲区”载入到“内核缓冲区”，最后写入到磁盘B文件。
这样写文件很累吧，于是有人觉得这里可以跳过“用户缓冲区”的拷贝。其实，这就是MMP（Memory-Mapping，内存映射）的实现，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”，而是返回一个指向内存空间的指针。于是，我们之前的读写文件例子，就会变成，A文件数据从磁盘载入到“内核缓冲区”，然后从“内核缓冲区”复制到B文件的“内核缓冲区”，B文件再从”内核缓冲区“写回到磁盘中。这个过程，减少了一次内存拷贝，同时也少内存占用。
好了，回到sendfile的话题上来，简单的说，sendfile的做法和MMP类似，就是减少数据从”内核态缓冲区“到”用户态缓冲区“的内存拷贝。
默认的磁盘文件读取，到传输给socket，流程（不使用sendfile）是：
使用sendfile之后：
这种方式，不仅节省了内存，而且还有CPU的开销。