<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Fresker小站 &#187; apache</title>
	<atom:link href="http://www.fresker.com/old2/archives/category/%e8%bd%af%e4%bb%b6%e5%bc%80%e5%8f%91/apache/feed" rel="self" type="application/rss+xml" />
	<link>http://www.fresker.com/old2</link>
	<description>天将降大任于斯人也，必先苦其心志，劳其筋骨，饿其体肤，空乏其身....</description>
	<lastBuildDate>Sat, 05 May 2018 04:20:42 +0000</lastBuildDate>
	<language></language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
		<item>
		<title>Ubuntu下配置Apache的Worker模式</title>
		<link>http://www.fresker.com/old2/archives/508</link>
		<comments>http://www.fresker.com/old2/archives/508#comments</comments>
		<pubDate>Fri, 13 Jul 2012 03:53:35 +0000</pubDate>
		<dc:creator>Duke</dc:creator>
				<category><![CDATA[apache]]></category>
		<category><![CDATA[开发技术类]]></category>
		<category><![CDATA[技术杂谈]]></category>
		<category><![CDATA[Apache]]></category>

		<guid isPermaLink="false">http://www.fresker.com/archives/508</guid>
		<description><![CDATA[其实Apache本身的并发能力是足够强大的，但是Ubuntu默认安装的是Prefork模式下的Apache。所以导致很多人后面盲目的去安装lighttpd或者nginx一类替代软件。但是这类软件有一定的兼容问题，部分情况下可能工作的并不好。那么， 是不是Apache并发就不行了呢？——答案当然是否定的。 在进行配置之前，我们首先要知道什么是Prefork模式，什么是Worker模式，什么是Event模式，以及什么是MPM。 MPM是Apache2引入的一个概念，就是将结构模块化。把核心任务处理作为一个可插拔的模块，即MPM，使其能针对不同的环境进行优化。在这个情况下，就诞生出了处理模式的概念。处理模式现在分为Prefork、Worker、Event三种。 Prefork MPM基于非线程模型，和Apache 1.x版本中的处理方式很相似。Prefork MPM在所有情况下都很安全，对运行非线程安全（non-thread-safe）模式的软件如PHP，它是唯一的安全选择。对于某些应用程序，包括在 Apache 1.3上非常流行的程序（如简单静态页面、CGI脚本等），Prefork MPM是最好的选择。另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的，这也使其成为最稳定的MPM之一。但是由于每一个请求都会产生一个新的进程，导致系统资源（尤其是内存）消耗的很快，一旦并发量较大的时候，大量的Apache进程会占用巨大的内存空间。 而Worker MPM基于线程模式，具有内存消耗低（对繁忙的服务很重要）、扩展性在某些特定应用情况下比Prefork更好等优点。在这个模式下，采用的进程和线程混合的形式处理请求。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的Prefork模式。 以上两种稳定的MPM方式在非常繁忙的服务器应用下都有些不足。尽管HTTP的Keepalive方式能减少TCP连接数量和网络负载，但是 Keepalive需要和服务进程或者线程绑定，这就导致一个繁忙的服务器会耗光所有的线程。Event MPM是解决这个问题的一种新模型，它把服务进程从连接中分离出来。在服务器处理速度很快，同时具有非常高的点击率时，可用的线程数量就是关键的资源限 制，此时Event MPM方式是最有效的。一个以Worker MPM方式工作的繁忙服务器能够承受每秒好几万次的访问量（例如在大型新闻服务站点的高峰时），而Event MPM可以用来处理更高负载。值得注意的是，Event MPM不能在安全HTTP（HTTPS）访问下工作。 一目了然，三种MPM模式各有各的优缺点。但是如果我们经常遇到访问量一大，服务器资源就吃紧的情况，那么就是Prefork模式瓶颈了。在其他两类MPM中，通用的做法还是使用Worker模式来解决问题。Event MPM由于不支持安全连接（HTTPS）所以导致应用有一定的局限性。 下面我们就以Ubuntu下将Apache的模式从Prefork设置为Worker为例，来说明一下操作步骤。前面也提到了，由于Worker模式与PHP的执行方式不同，所以如果简单的输入apt-get install apache2-mpm-worker，会导致PHP无法使用。当然了，如果你的网页只有静态页面，不需要使用PHP，那么使用上面这条指令就会搞定一切。这里我们着重讨论下要使用PHP的情况下，应该如何配置Apache的Worker模式。 1. 安装Apache的fcgid模块，使用它来启用PHP。 #apt-get install libapache2-mod-fcgid 2. 设置fcgid模块的配置文件，使其能够调用PHP。 #vim /etc/apache2/mods-available/fcgid.conf 将文件内的原来文本全部删除掉，然后添加下面的文本： &#60;IfModule mod_fcgid.c&#62;AddHandler fcgid-script .php .py .pl .fcgiSocketPath /var/lib/apache2/fcgid/sockIPCConnectTimeout 20&#60;/IfModule&#62; 3. 安装php5-cgi。 #apt-get install php5-cgi 4. 设置Apache的配置文件，使其能够调用fcgid模块来启动PHP。 #vim /etc/apache2/apache2.conf 在文件最后添加下面的内容： [...]]]></description>
		<wfw:commentRss>http://www.fresker.com/old2/archives/508/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Apache MPM Prefork模式参数调优方法</title>
		<link>http://www.fresker.com/old2/archives/507</link>
		<comments>http://www.fresker.com/old2/archives/507#comments</comments>
		<pubDate>Fri, 13 Jul 2012 03:53:16 +0000</pubDate>
		<dc:creator>Duke</dc:creator>
				<category><![CDATA[apache]]></category>
		<category><![CDATA[开发技术类]]></category>
		<category><![CDATA[技术杂谈]]></category>
		<category><![CDATA[Apache]]></category>

		<guid isPermaLink="false">http://www.fresker.com/archives/507</guid>
		<description><![CDATA[Apache配置文件中有非常多的参数，绝大多数Apache都是运行于mpm_prefork模式下，而对prefork参数的调试至关重要。prefork模式对每个不同的请求使用不同的进程，因此能够避免非常多的安全问题。它具有强大的自我调节能力，能够比较智能的适应不同压力的访问。 调整性能参数并非纸上谈兵，需要在调整的每一步都对服务器进行负载压力测试，以确保在服务器稳定的基础下实现最高的性能。 参数解释 Apache的MPM配置文件主要有如下几段： 平板视图 打印？ 1 &#60;IfModule mpm_prefork_module&#62; 2 StartServers 10 3 MinSpareServers 5 4 MaxSpareServers 15 5 MaxClients 200 6 MaxRequestsPerChild 5000 7 &#60;/IfModule&#62; 其中MaxClients、MinSpareServers与MaxSpareServers是关键。 MaxClients决定了Apache最多创建多少个子进程用来处理请求。进一步举例解释，如果这个参数设置为200（如图），则当Apache主进程收到大量请求时，会创建最多200个进程。而这200个进程用于处理这些请求。因此，无论有多少个请求，也只会有200个进程并行处理。 MaxSpareServers顾名思义是“最多空闲进程”，注意“空闲”二字。接上一个例子，当这200个进程处理完了所有的请求后，这些进程便都“空闲”了。此时Apache便会杀死一些进程以释放资源。那么，如上图设置，Apache会保留最多15个空闲的进程； MinSpareServers是“最少空闲进程”。当Apache启动时，如果空闲的进程少于5个，则会以一定频率创建新的进程，直到满足这个数值（5）。这样设计的目的是为了让Apache更迅速的应付潜在的访问高峰。 StartServers表示Apache在启动的时候创建的进程数量。如果访问压力很大，那么进程数会逐步增加，直到达到MaxClients设置的数量。 MaxRequestPerChild表示每个进程处理的最大请求数。当任何一个子进程处理的请求数达到MaxRequestPerChild后，便会自杀。如果MaxRequestPerChild设置为0，表示不限（即永远不自杀）。这种机制的作用是防止潜在的内存泄露。如果Apache的某个模块，或者某段php脚本可能导致内存泄露，而处理进程却又永远不退出，则很可能造成服务器内存剧增最终崩溃。当开启这个机制后，无论是否存在内存泄露，都会让进程在处理一定数量的请求后退出，同时释放所有内存。 调优约束条件 MaxClients参数的最佳值在很大程度上取决于内存大小。此参数调优的目标即当Apache处在最多子进程数状态时，服务器不会使用swap。如果此数值的设置过大，则Apache在访问高峰期会创建过多的子进程，导致Linux使用swap来作为内存。而swap的效率非常低，并且会导致磁盘压力增大，形成恶性循环。 如果希望Apache能在访问非高峰期过后能够迅速的释放资源，则MaxSpareServers应该设置得略低，让Apache迅速杀死过多的子进程； 如果希望Apache能够迅速应对突如其来的访问高峰，则应将MinSpareServers设置高一点，让Apache创建较多的空闲（备用）进程。 而MaxRequestPerChild对性能的影响则没有那么明显。如果MaxRequestPerChild设置偏小，则Apache可能会在访问高峰期时，把大量的CPU消耗在创建/杀死进程上，造成不必要的CPU损耗。 Prefork机制 prefork 控制进程在最初建立“StartServers”个子进程后，为了满足MinSpareServers设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足MinSpareServers设置的值为止。 这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。MaxSpareServers设置了最大的空闲进程数，如果空闲进程数大于这个值，Apache会自动kill掉一些多余进程。这个值不要设得过大，但如果设的值比MinSpareServers小，Apache会自动把其调整为 MinSpareServers+1。 如果站点负载较大，可考虑同时加大MinSpareServers和MaxSpareServers。 MaxRequestsPerChild设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild”个请求后将自动销毁。 通过 Wiz 发布]]></description>
		<wfw:commentRss>http://www.fresker.com/old2/archives/507/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Apache Prefork和Worker模式的性能比较测试</title>
		<link>http://www.fresker.com/old2/archives/506</link>
		<comments>http://www.fresker.com/old2/archives/506#comments</comments>
		<pubDate>Fri, 13 Jul 2012 03:52:53 +0000</pubDate>
		<dc:creator>Duke</dc:creator>
				<category><![CDATA[apache]]></category>
		<category><![CDATA[开发技术类]]></category>
		<category><![CDATA[技术杂谈]]></category>
		<category><![CDATA[Apache]]></category>
		<category><![CDATA[项目环境搭建]]></category>

		<guid isPermaLink="false">http://www.fresker.com/archives/506</guid>
		<description><![CDATA[选择prefork还是worker可以在编译时使用–with-mpm=MPM参数指定,默认为prefork, prefork prefork采用预派生子进程方式，用单独的子进程来处理 不同的请求，进程之间彼此独立。在make编译和make install安装后，使用httpd -l来确定当前使用的MPM是prefork.c。查看httpd-mpm.conf配置文件，里面包含如下默认的配置段： &#60;IfModule prefork.c&#62;StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 &#60;/IfModule&#62;prefork 控制进程在最初建立“StartServers”个子进程后，为了满足MinSpareServers设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足MinSpareServers设置的值为止。这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。MaxSpareServers设置了最大的空闲进程数，如果空闲进程数大于这个值，Apache会自动kill掉一些多余进程。这个值不要设得过大，但如果设的值比MinSpareServers小，Apache会自动把其调整为 MinSpareServers+1。如果站点负载较大，可考虑同时加大MinSpareServers和MaxSpareServers。 MaxRequestsPerChild设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild”个请求后将自动销毁。0意味着无限，即子进程永不销毁。虽然缺省设为0可以使每个子进程处理更多的请求，但如果设成非零值也有两点重要的好处：1、可防止意外的内存泄漏。2、在服务器负载下降的时侯会自动减少子进程数。因此，可根据服务器的负载来调整这个值。MaxClients是这些指令中最为重要的一个，设定的是 Apache可以同时处理的请求，是对Apache性能影响最大的参数。其缺省值150是远远不够的，如果请求总数已达到这个值（可通过ps -ef&#124;grep http&#124;wc -l来确认），那么后面的请求就要排队，直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。虽然理论上这个值越大，可以处理的请求就越多，但Apache默认的限制不能大于256。ServerLimit指令无须重编译Apache就可以加大MaxClients。 &#60;IfModule prefork.c&#62; ServerLimit&#160; 10000StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 10000 MaxRequestsPerChild 0 &#60;/IfModule&#62; &#160; Worker相对于prefork，worker全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是，worker也使用了多进程，每个进程又生成多个线程，以获得基于进程服务器的稳定性。在configure –with-mpm=worker后，进行make编译、make install安装。在缺省生成的httpd-mpm.conf中有以下默认配置段：&#60;IfModule worker.c&#62; StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild [...]]]></description>
		<wfw:commentRss>http://www.fresker.com/old2/archives/506/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Apache的prefork模式和worker模式</title>
		<link>http://www.fresker.com/old2/archives/505</link>
		<comments>http://www.fresker.com/old2/archives/505#comments</comments>
		<pubDate>Fri, 13 Jul 2012 03:49:33 +0000</pubDate>
		<dc:creator>Duke</dc:creator>
				<category><![CDATA[apache]]></category>
		<category><![CDATA[开发工具]]></category>
		<category><![CDATA[开发技术类]]></category>
		<category><![CDATA[Apache]]></category>
		<category><![CDATA[项目环境搭建]]></category>

		<guid isPermaLink="false">http://www.fresker.com/archives/505</guid>
		<description><![CDATA[prefork模式这个多路处理模块(MPM)实现了一个非线程型的、预派生的web服务器，它的工作方式类似于Apache 1.3。它适合于没有线程安全库，需要避免线程兼容性问题的系统。它是要求将每个请求相互独立的情况下最好的MPM，这样若一个请求出现问题就不会影响到其他请求。 这个MPM具有很强的自我调节能力，只需要很少的配置指令调整。最重要的是将MaxClients设置为一个足够大的数值以处理潜在的请求高峰，同时又不能太大，以致需要使用的内存超出物理内存的大小。 worker模式此多路处理模块(MPM)使网络服务器支持混合的多线程多进程。由于使用线程来处理请求，所以可以处理海量请求，而系统资源的开销小于基于进程的MPM。但是，它也使用了多进程，每个进程又有多个线程，以获得基于进程的MPM的稳定性。 控制这个MPM的最重要的指令是，控制每个子进程允许建立的线程数的ThreadsPerChild指令，和控制允许建立的总线程数的MaxClients指令。 prefork和worker模式的切换1.将当前的prefork模式启动文件改名mv httpd httpd.prefork2.将worker模式的启动文件改名mv httpd.worker httpd3.修改Apache配置文件vi /usr/local/apache2/conf/extra/httpd-mpm.conf找到里边的如下一段，可适当修改负载等参数：&#60;IfModule mpm_worker_module&#62;StartServers 2MaxClients 150MinSpareThreads 25MaxSpareThreads 75ThreadsPerChild 25MaxRequestsPerChild 0&#60;/IfModule&#62;4.重新启动服务/usr/local/apache2/bin/apachectl restart即可换成worker方式启动apache2 处于稳定性和安全性考虑，不建议更换apache2的运行方式，使用系统默认prefork即可。另外很多php模块不能工作在worker模式下，例如redhat linux自带的php也不能支持线程安全。所以最好不要切换工作模式。 prefork和worker模式的比较prefork模式使用多个子进程，每个子进程只有一个线程。每个进程在某个确定的时间只能维持一个连接。在大多数平台上，Prefork MPM在效率上要比Worker MPM要高，但是内存使用大得多。prefork的无线程设计在某些情况下将比worker更有优势：它可以使用那些没有处理好线程安全的第三方模块，并且对于那些线程调试困难的平台而言，它也更容易调试一些。 worker模式使用多个子进程，每个子进程有多个线程。每个线程在某个确定的时间只能维持一个连接。通常来说，在一个高流量的HTTP服务器上，Worker MPM是个比较好的选择，因为Worker MPM的内存使用比Prefork MPM要低得多。但worker MPM也由不完善的地方，如果一个线程崩溃，整个进程就会连同其所有线程一起&#8221;死掉&#8221;.由于线程共享内存空间，所以一个程序在运行时必须被系统识别为&#8221;每个线程都是安全的&#8221;。 总的来说，prefork方式速度要稍高于worker，然而它需要的cpu和memory资源也稍多于woker。 prefork模式配置详解&#60;IfModule mpm_prefork_module&#62;ServerLimit 256StartServers 5MinSpareServers 5MaxSpareServers 10MaxClients 256MaxRequestsPerChild 0&#60;/IfModule&#62;ServerLimit默认的MaxClient最大是256个线程,如果想设置更大的值，就的加上ServerLimit这个参数。20000是ServerLimit这个参数的最大值。如果需要更大，则必须编译apache,此前都是不需要重新编译Apache。生效前提：必须放在其他指令的前面 StartServers指定服务器启动时建立的子进程数量，prefork默认为5。 MinSpareServers指定空闲子进程的最小数量，默认为5。如果当前空闲子进程数少于MinSpareServers ，那么Apache将以最大每秒一个的速度产生新的子进程。此参数不要设的太大。 MaxSpareServers设置空闲子进程的最大数量，默认为10。如果当前有超过MaxSpareServers数量的空闲子进程，那么父进程将杀死多余的子进程。此参数不要设的太大。如果你将该指令的值设置为比MinSpareServers小，Apache将会自动将其修改成&#8221;MinSpareServers+1&#8243;。 MaxClients限定同一时间客户端最大接入请求的数量(单个进程并发线程数)，默认为256。任何超过MaxClients限制的请求都将进入等候队列,一旦一个链接被释放，队列中的请求将得到服务。要增大这个值，你必须同时增大ServerLimit。 MaxRequestsPerChild每个子进程在其生存期内允许伺服的最大请求数量，默认为10000.到达MaxRequestsPerChild的限制后，子进程将会结束。如果MaxRequestsPerChild为&#8221;0&#8243;，子进程将永远不会结束。将MaxRequestsPerChild设置成非零值有两个好处：1.可以防止(偶然的)内存泄漏无限进行，从而耗尽内存。2.给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。 worker模式配置详解&#60;IfModule mpm_worker_module&#62;StartServers 2MaxClients 150MinSpareThreads 25MaxSpareThreads 75ThreadsPerChild 25MaxRequestsPerChild 0&#60;/IfModule&#62; StartServers服务器启动时建立的子进程数，默认值是&#8221;3&#8243;。 MaxClients允许同时伺服的最大接入请求数量(最大线程数量)。任何超过MaxClients限制的请求都将进入等候队列。默认值是&#8221;400&#8243;,16(ServerLimit)乘以25(ThreadsPerChild)的结果。因此要增加MaxClients的时候，你必须同时增加ServerLimit的值。 MinSpareThreads最小空闲线程数,默认值是&#8221;75&#8243;。这个MPM将基于整个服务器监视空闲线程数。如果服务器中总的空闲线程数太少，子进程将产生新的空闲线程。 [...]]]></description>
		<wfw:commentRss>http://www.fresker.com/old2/archives/505/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->