Apache 的动态静态编译 &工作模式MPM

apache 动态编译与静态编译
首先是默认的静态编译安装这些模块是默认的:

[root@doita bin]#./apachectl -lCompiled in modules:  core.c  mod_authn_file.c  mod_authn_default.c  mod_authz_host.c  mod_authz_groupfile.c  mod_authz_user.c  mod_authz_default.c  mod_auth_basic.c  mod_include.c  mod_filter.c  mod_log_config.c  mod_env.c  mod_setenvif.c  mod_version.c  prefork.c  http_core.c  mod_mime.c  mod_status.c  mod_autoindex.c  mod_asis.c  mod_cgi.c  mod_negotiation.c  mod_dir.c  mod_actions.c  mod_userdir.c  mod_alias.c  mod_so.c

关于动态安装的优缺点 官方文档给出了如下说明:

上述基于DSO的功能有如下优点：
由于服务器包的装配工作可以在运行时使用httpd.conf中的配置命令LoadModule来进行，而不是在编译中使用编译选项来进行，因此显得更灵活。比如，只需要安装一个Apache，就可以运行多个不同的服务器实例(如标准&SSL版本，浓缩&功能加强版本[mod_perl、PHP])。

服务器可以在安装后使用第三方模块被轻易地扩展。这至少对厂商发行包的维护者有巨大的好处，他可以建立一个Apache核心包，而为诸如PHP、mod_perl、mod_fastcgi等扩展另建附加的包。
更简单的Apache模块原型。使用DSO配合apxs，可以脱离Apache源代码树，仅需要一个 apxs -i 和一个 apachectl restart 命令，就可以把刚开发的新模块纳入到运行中的Apache服务器。

DSO有如下缺点：
由于并不是所有操作系统都支持动态加载代码到一个程序的地址空间，因此DSO机制并不能用于所有平台。
由于Unix加载器必须进行符号解析，服务器的启动会慢20%左右。
在某些平台上，位置独立代码(positon independent code[PIC])需要复杂的汇编语言技巧来实现相对寻址，而绝对寻址则不需要，因此服务器在运行时会慢5%左右。
由于DSO模块不能在所有平台上被其他基于DSO的库所连接(ld -lfoo)，比如，基于a.out的平台通常不提供此功能，而基于ELF的平台则提供，因此DSO机制并不能被用于所有类型的模块。或者可以这样说，编译为DSO文件的模块只能使用由Apache核心、C库(libc)和Apache核心所用的所有其他动态或静态的库、含有独立位置代码的静态库(libfoo.a)所提供的符号。而要使用其他代码，就只能确保Apache核心本身包含对此代码的引用，或者自己用dlopen()来加载此代码。
动态编译其实就是把哪些模块独立起来,脱离了apache本身的二进制主体部分.默认加载.so文件的模块是在apache主体中的.动态编译有几个选项,将上面的模块部分进行动态编译的.

  --enable-mods-shared=max  所有标准的动态模块都编译为dso   --enable-mods-shared=most 常用的,把那些不常用的放在一边.   --enable-mods-shared=all  意思是动态加载所有模块，如果去掉-shared话，是静态加载所有模块

以上为2.0以后的版本,对于1.3之前的版本,语法有所不同.
(参考如下http://apps.hi.baidu.com/share/detail/21938370)

客户环境的静态编译modules为

bash-3.00# apachectl -l  Compiled in modules:  core.c  prefork.c  http_core.c  mod_so.c

以上是2.0的,后来证实是版本问题.2.2之后多了很多静态模块.

使用静态与动态模块的语法不同:静态的可以直接使用,而动态的需要加载 如下

LoadModule access_module modules/mod_access.soLoadModule auth_module modules/mod_auth.soLoadModule auth_anon_module modules/mod_auth_anon.so

在动态编译时,可能需要zlib-devel 来支持服务器端压缩传输功能.

转自：http://blog.chinaunix.net/uid-24799710-id-3030355.html

三种MPM介绍

　Apache 2.X 支持插入式并行处理模块，称为多路处理模块（MPM）。在编译apache时必须选择也只能选择一个MPM，对类UNIX系统，有几个不同的MPM可供选择，它们会影响到apache的速度和可伸缩性。

　　Prefork MPM : 这个多路处理模块(MPM)实现了一个非线程型的、预派生的web服务器，它的工作方式类似于Apache 1.3。它适合于没有线程安全库，需要避免线程兼容性问题的系统。它是要求将每个请求相互独立的情况下最好的MPM，这样若一个请求出现问题就不会影响到其他请求。

　　这个MPM具有很强的自我调节能力，只需要很少的配置指令调整。最重要的是将MaxClients设置为一个足够大的数值以处理潜在的请求高峰，同时又不能太大，以致需要使用的内存超出物理内存的大小。

　　Worker MPM : 此多路处理模块(MPM)使网络服务器支持混合的多线程多进程。由于使用线程来处理请求，所以可以处理海量请求，而系统资源的开销小于基于进程的MPM。但是，它也使用了多进程，每个进程又有多个线程，以获得基于进程的MPM的稳定性。

　　每个进程可以拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程可以建立ThreadsPerChild数量的服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。

　　不管是Worker模式或是Prefork 模式，Apache总是试图保持一些备用的(spare)或者是空闲的子进程（空闲的服务线程池）用于迎接即将到来的请求。这样客户端就不需要在得到服务前等候子进程的产生。

　　Event MPM：以上两种稳定的MPM方式在非常繁忙的服务器应用下都有些不足。尽管HTTP的Keepalive方式能减少TCP连接数量和网络负载，但是 Keepalive需要和服务进程或者线程绑定，这就导致一个繁忙的服务器会耗光所有的线程。 Event MPM是解决这个问题的一种新模型，它把服务进程从连接中分离出来。在服务器处理速度很快，同时具有非常高的点击率时，可用的线程数量就是关键的资源限 制，此时Event MPM方式是最有效的。一个以Worker MPM方式工作的繁忙服务器能够承受每秒好几万次的访问量（例如在大型新闻服务站点的高峰时），而Event MPM可以用来处理更高负载。值得注意的是，Event MPM不能在安全HTTP（HTTPS）访问下工作。

对于Event 模式，apache给出了以下警告：

This MPM is experimental, so it may or may not work as expected .

这种MPM目前处于试验状态，他可能不能按照预期的那样工作。