Apache简单优化

1.重新编译Apache。

Apache的默认配置不是为了最大化性能而设置的，而是考虑到向后兼容性和平台兼容性的问题。因此很多2.x的新特性没有能够体现出来。在编译的时候，需要加入一些参数，增加的这些模块应该会大幅的提高性能。

既然重新编译，建议使用最新的2.2版，里面有些部分对性能有不少加强。

2.编译的时候建议加入下面的参数
./buildconf
./configure \
 --with-mpm=worker \
 --enable-cache --enable-disk-cache --enable-mem-cache --enable-file-cache \
 --enable-nonportable-atomics \
 --enable-mods-shared=most

2.1 Multi-Processing Modules (MPM)

--with-mpm={prefork,worker}

这个是设置Apache的多任务处理的。prefork是指每个连接一个进程，也就是多进程并行处理；而worker是多线程并行处理。支持多线程处理，本来是Apache 2的一大改进，可是为了和以前的兼容，所以对于Unix默认的都是prefork，这个改进并没有体现出来。而这个设置只能在编译的时候进行优化，这也是为什么一定要重新编译一下apache的原因。

apache文档这么说：

“·worker MPM 使用多进程，每个进程包含多线程的方式。每个线程一次处理一个连接。worker对于高流量的服务器通常是一个好的选择，因为它比prefork MPM占用更少的内存。
·prefork MPM 使用多进程，每个进程只包含1个线程的方式。每个进程一次处理一个连接。在许多系统上，prefork具有与worker相媲美的速度，但是它会占用更多的内存。prefork的无线程设计在某些情况下将比worker更有优势：它可以使用那些没有处理好线程安全的第三方模块，并且对于那些线程调试困难的平台而言，它也更容易调试一些。”

这么说确实没有什么必要用prefork，刚才看了一下FC5，也是用的prefork模式。所以重新编译apache是肯定的了。我还不知道哪个Linux发布版本的apache默认是worker的呢。

为了设置MPM为worker需要设置：

--with-mpm=worker

2.2 Caching

mod_cache是从mod_proxy分离出来的。在以前apache 1.3的时候，就已经在mod_proxy中支持缓冲技术了。现在是为了加强缓冲能力，从mod_proxy中独立出来，而mod_proxy被完全重写了，更强调代理的作用了。

从Apache 2.2开始，mod_cache将不再是实验模块而作为稳定模块发布了。为了能够支持cache，需要在编译的时候，启用它，因为默认caching是禁用的。我估计是因为以前还是实验模块，所以还是为了向后兼容的问题，暂时是默认禁用的。

mod_cache一共有三种mod_mem_cache,mod_disk_cache和mod_file_cache。具体怎么用可以看apache的文档，虽然是英文，不过不是很难懂：

网上也有一些关于mod_cache的中文配置文章可以参考。

总值为了能够用cache，需要在编译的时候设置：

--enable-cache --enable-disk-cache --enable-mem-cache --enable-file-cache

2.3 原子操作

有些模块中，如mod_cache中使用了一些原子操作，多任务中的互斥量操作之类的。为了可移植性，一般都是用互斥量环绕条件语句来判断来实现。比如：

acquire_lock(mutex);
if( a == 0 ){
   a = 3;
}
release_lock(mutex);

加锁的目的是确保if和赋值不会被其他线程中断。可是有些cpu中提供了一条指令来做判断赋值，不需要这么复杂的操作，比如486加入的指令：

cmpxchg [edx], eax

先测试[edx]是否为0，如果为0，就让[edx]=eax。

通过硬件保证了中间不会被中断。要知道一旦用到了互斥量，那么线程切换的等待就避免不了，这对于线程太多并且有公用数据的程序来说，影响性能的因素之一。因此一旦得到了硬件的直接支持。在多线程程序的处理上，就少了很多的锁，也就提高了一定的性能。但是，不是所有的cpu都有这样的指令，因此默认情况下还是使用锁的老办法。除非编译时明确声明：

--enable-nonportable-atomics=yes

需要注意的是，这样编译后，只能用在486及其以上的计算机中。我估计一般的服务器不是跑在386上吧。呵呵，对了，也尽量不要是64位的系统。

2.4 允许后期动态加载模块

--enable-mods-shared=most

这将编译大部分的模块为动态模块，这样后期可以动态的调入。默认情况竟然是不允许，太令我诧异了。呵呵。我感觉对于典型的多进程应用，模块就应该是动态加载，这样比较节省内存空间，反正大家用得都差不多的模块。

3. 检查

至于是否还想加其他的模块你就看着办吧，一般来说这就够了。

需要提一下的是，现在apache在2.2种引入了一种新的MPM来提高性能，叫做event。可惜还在实验状态，未能稳定。event是worker的变种，和线程类似，也是多线程模型，不同的是，它将做数据处理的线程和等待连接的线程分开，以此试图解决KeepAlive大了也不是，小了也不是的性能调整问题。

event是使用一个比较小的线程来等待所有的socket，包括等候连接的socket和那些KeepAlive的连接。一旦这些socket有任何发送HTTP请求了，这个等候的线程，就会这个socket交给真正做数据处理的线程进行处理，那个线程处理完成后，会将这个socket交还给这个守候线程。

这样，即使有大量的KeepAlive连接，也不用担心性能损耗，因为只有一个简单的线程来负责维护这些KeepAlive的连接，而那些真正做任务处理的线程则在一个HTTP响应处理完成后就退回到可用线程池或者被释放了，因此很省资源。这个思路很好，现在还在实验，如果试验成功，估计会成为2.4或者2.6的稳定MPM。

3.1 httpd -l

通过这条命令可以检查mpm是prefork还是worker。很不幸默认是prefork，FC5显示如下：

Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

3.2 apachectl -l

通过这条指令可以检查cache模块的加载情况，很不幸，默认是啥都没有。

4. KeepAlive

我看到KeepAlive默认设置为On，KeepAliveTimeout默认是5秒。这个设置的含义时说，对于HTTP/1.1的客户端来说，将会尽量的保持客户的HTTP连接，通过一个连接传送多份HTTP请求<->响应。这样对于客户端来说，可以提高50%左右的响应时间，而对于服务端来说则降低了更多个连接的开销。不过这个依赖于客户端是否想保持连接。我知道IE默认是保持连接的，当你打开100个图片的网站时，IE好像只开2个连接，通过这两个连接传送数据，而不是开100个连接。KeepAliveTimeout时说这次连接结束后开始计时，如果5秒内没有重新发送HTTP请求，就断掉连接。这个值可以稍微大一点，但是不可太大，否则会出现同时等候过多的连接，导致过多限制资源，而使服务器性能下降。可以调调看。