Posts Tagged www
Apache 2.0性能优化—MPM的选择与配置
Apache 2.0在性能上的改善最吸引人。在支持POSIX线程的Unix系统 上,Apache可以通过不同的MPM运行在一种多进程与多线程相混合的模式下,增强部分配置的可扩充性能。相比于Apache 1.3,2.0版本做了 大量的优化来提升处理能力和可伸缩性,并且大多数改进在默认状态下即可生效。但是在编译和运行时刻,2.0也有许多可以显著提高性能的选择。本文不想叙述 那些以功能换取速度的指令,如HostnameLookups等,而只是说明在2.0中影响性能的最核心特性:MPM(Multi - Processing Modules,多道处理模块)的基本工作原理和配置指令。
毫不夸张地说,MPM的引入是 Apache 2.0最重要的变化。大家知道,Apache是基于模块化的设计,而Apache 2.0更扩展了模块化设计到Web服务器的最基本功能。 服务器装载了一种多道处理模块,负责绑定本机网络端口、接受请求,并调度子进程来处理请求。扩展模块化设计有两个重要好处:
◆ Apache可以更简洁、有效地支持多种操作系统;
◆ 服务器可以按站点的特殊需要进行自定制。
在用户级,MPM看起来和其它Apache模块非常类似。主要区别是在任意时刻只能有一种MPM被装载到服务器中。
指定MPM的方法
下面以Red Hat Linux 9为平台,说明在Apache 2.0中如何指定MPM (Apache采用2.0.45)。先解压缩源代码包 httpd-2.0.45.tar.gz,生成httpd-2.0.45目录(Apache 1.3源代码包的命名规则是 apache_1.3.NN.tar.gz,而2.0版则是httpd-2.0.NN.tar.gz,其中NN是次版本号)。
进入httpd-2.0.45目录,运行以下代码:
$ ./configure –help|grep mpm
显示如下:
–with-mpm=MPM
Choose the process model for Apache to use.
MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool}
上述操作用来选择要使用的进程模型,即哪种MPM模块。Beos、mpmt_os2分别是BeOS和OS/2上缺省的MPM, perchild主要设 计目的是以不同的用户和组的身份来运行不同的子进程。这在运行多个需要CGI的虚拟主机时特别有用,会比1.3版中的SuExec 机制做得更好。 leader和threadpool都是基于worker的变体,还处于实验性阶段,某些情况下并不会按照预期设想的那样工作,所以 Apache官方也 并不推荐使用。因此,我们主要阐述prefork和worker这两种和性能关系最大的产品级MPM ( 有关其它的MPM详细说明,请参见Apache 官方文档:http://httpd.apache.org/docs-2.0/mod/)。
prefork的工作原理及配置
如果不用“–with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache 1.3中采用的模式。prefork本身并没有使用到线程,2.0版使用它是为了与1.3版保持兼容性;另一方面,prefork用单独 的子进程来处理不同的请求,进程之间是彼此独立的,这也使其成为最稳定的MPM之一。
若使用prefork,在make编译和 make install安装后,使用“httpd -l”来确定当前使用的MPM,应该会看到prefork.c(如果看到worker.c说明使用的 是worker MPM,依此类推)。再查看缺省生成的httpd.conf配置文件,里面包含如下配置段:
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
prefork的工作原理是,控制进程在最初建立“StartServers”个子进程后,为了满足MinSpareServers设置的需要创建一个 进程,等待一秒钟,继续创建两个,再等待一秒钟,继续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足 MinSpareServers设置的值为止。这就是预派生(prefork)的由来。这种模式可以不必在请求到来时再产生新的进程,从而减小了系统开 销以增加性能。
MaxSpareServers设置了最大的空闲进程数,如果空闲进程数大于这个值,Apache会自动kill 掉一些多余进程。这个值不要设得过大,但如果设的值比MinSpareServers小,Apache会自动把其调整为MinSpareServers+ 1。如果站点负载较大,可考虑同时加大MinSpareServers和MaxSpareServers。
MaxRequestsPerChild设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild” 个请求后将 自动销毁。0意味着无限,即子进程永不销毁。虽然缺省设为0可以使每个子进程处理更多的请求,但如果设成非零值也有两点重要的好处:
◆ 可防止意外的内存泄漏;
◆ 在服务器负载下降的时侯会自动减少子进程数。
因此,可根据服务器的负载来调整这个值。笔者认为10000左右比较合适。
MaxClients是这些指令中最为重要的一个,设定的是Apache可以同时处理的请求,是对Apache性能影响最大的参数。其缺省值 150是 远远不够的,如果请求总数已达到这个值(可通过ps -ef|grep http|wc -l来确认),那么后面的请求就要排队,直到某个已处理请求完 毕。这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。系统管理员可以根据硬件配置和负载情况来动态调整这个值。虽然理论上这个值越大,可以处理 的请求就越多,但Apache默认的限制不能大于256。如果把这个值设为大于256,那么 Apache将无法起动。事实上,256对于负载稍重的站点 也是不够的。在Apache 1.3中,这是个硬限制。如果要加大这个值,必须在“configure”前手工修改的源代码树下的 src/include/httpd.h中查找 256,就会发现“#define HARD_SERVER_LIMIT 256”这行。把256改为要 增大的值(如4000),然后重新编译Apache即可。在Apache 2.0中新加入了ServerLimit指令,使得无须重编译Apache就可 以加大MaxClients。下面是笔者的prefork配置段:
<IfModule prefork.c>
StartServers 10
MinSpareServers 10
MaxSpareServers 15
ServerLimit 2000
MaxClients 1000
MaxRequestsPerChild 10000
</IfModule>
上述配置中,ServerLimit的最大值是20000,对于大多数站点已经足够。如果一定要再加大这个数值,对位于源代码树下server/mpm/prefork/prefork.c中以下两行做相应修改即可:
#define DEFAULT_SERVER_LIMIT 256
#define MAX_SERVER_LIMIT 20000
worker的工作原理及配置
相对于prefork,worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理,所以可以处理相对海量的请求,而系 统资源的开销要小于基于进程的服务器。但是, worker也使用了多进程,每个进程又生成多个线程,以获得基于进程服务器的稳定性。这种MPM的工作方 式将是Apache 2.0的发展趋势。
在configure -with-mpm=worker后,进行make编译、make install安装。在缺省生成的httpd.conf中有以下配置段:
<IfModule worker.c>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
worker的工作原理是,由主控制进程生成“StartServers”个子进程,每个子进程中包含固定的ThreadsPerChild 线程数, 各个线程独立地处理请求。同样,为了不在请求到来时再生成线程,MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲 线程数;而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载,控制进程将派生新的子进程。
MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大,可以按照实际情况相应调节。
ThreadsPerChild是worker MPM中与性能相关最密切的指令。ThreadsPerChild的最大缺省值是64,如果负载较大, 64也是不够的。这时要显式使用 ThreadLimit指令,它的最大缺省值是20000。上述两个值位于源码树 server/mpm/worker/worker.c中的以下两行:
#define DEFAULT_THREAD_LIMIT 64
#define MAX_THREAD_LIMIT 20000
这两行对应着ThreadsPerChild和ThreadLimit的限制数。最好在configure之前就把64改成所希望的值。注意,不要把这两个值设得太高,超过系统的处理能力,从而因Apache不起动使系统很不稳定。
Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的,应该大于等于MaxClients。如果负载很 大,现有的子进程数不能满足时,控制进程会派生新的子进程。默认最大的子进程总数是16,加大时也需要显式声明ServerLimit(最大值是 20000)。这两个值位于源码树server/mpm/worker/worker.c中的以下两行:
#define DEFAULT_SERVER_LIMIT 16
#define MAX_SERVER_LIMIT 20000
需要注意的是,如果显式声明了ServerLimit,那么它乘以ThreadsPerChild的值必须大于等于MaxClients,而且 MaxClients必须是ThreadsPerChild的整数倍,否则Apache将会自动调节到一个相应值(可能是个非期望值)。下面是笔者的 worker配置段:
<IfModule worker.c>
StartServers 3
MaxClients 2000
ServerLimit 25
MinSpareThreads 50
MaxSpareThreads 200
ThreadLimit 200
ThreadsPerChild 100
MaxRequestsPerChild 0
</IfModule>
通过上面的叙述,可以了解到Apache 2.0中prefork和worker这两个重要MPM的工作原理,并可根据实际情况来配置Apache相关的核心参数,以获得最大的性能和稳定性。
其它更详细的写以到http://httpd.apache.org/docs-2.0/
用FreeBSD的ports安装apache+php+mysql
化简为繁——优化你的网站层次
/*
############################################################################
#本文原作者: Litrin Jiang
#原文出处:www.litrin.net
#如需转载,请注明出处,谢谢!
############################################################################
*/
什么是层次?
史力克:就像洋葱。
当奇:为什么是洋葱,为什么不是泡芙?
史力克:因为洋葱有层次!!
常见的网站层次:
-
一层结构:
结构非常简单,只支持服务器端静态页面,网页文件数据直接从服务器硬盘中读出,经过www服务器传输给浏览器。
-
两层结构:
支持服务器端动态页面,页面文件经过处理后通过服务器传输给浏览器。最常见的3大页面语言:asp(iis) php(php+apache) jsp(tomcat).
-
最常用的3层结构:
这就比较完善了,数据流程:数据库->脚本解释->www服务器->浏览器。常见的IIS+sql(access) LAMP Tomcat+oracle等等一系列的经典搭配全都是说的这三层结构。
-
几种变种:
多数据库结构,多用于数据库端负荷较重的场合,将数据库分开存放,减轻负担。同时可使用数据库同步技术或者负载均衡技术(其实使用负载均衡逻辑上应该只算一台数据库)。
ps: 传说网易采用了2个数据库专门负责写数据,4个数据库专门负责读数据,中间采用数据同步技术保持数据同步。
放在这里将有点牵强,其实这不能算作服务器技术,而应该算作页面技术,多见于门户网站的论坛——将页面做成框架,通过cookies同步数据。如果要保持同步,笔者曾经听说过http server技术,但没有采用过。
页面缓存、缓冲技术
-
客户端缓存:
似乎没有什么好解释的:设定页面过期时间,客户端的浏览器就会自动缓存的。
-
“动转静”缓存:
原理就是将动态的网站转换成静态,从而达到减轻服务器负担和加速优化的目的。其转换出来文件名类似于***年*月*日-*****.html或者类似的,有些类似于***,***,***,*.html用“,”隔开的其实是传递的地址变量。具体生成这些文件的软件大多都是商业软件,如果哪位朋友发现有开源的产品,麻烦告诉我,在此感谢!
-
逆向代理缓存:
类似于http代理上网的原理,不过将他倒了过来,反向代理,本站也介绍过相应的配置方法,这种方法其实很常用,blogchina.com也用了类似的技术。(原先曾经有人问过我如何看出采用采用了页面缓冲,其实只要看它的http头,类似于“Server: squid/2.5.STABLE7”的就是了,看,版本号都有!)据我所知现在主要通过squid做缓冲,市面上也有所谓的网站加速器之类的硬件产品,实际上就是一个类似的嵌入产品。
PS:如果是采用了动态生成的页面,还要在脚本中稍加修改,具体方法烦请察看站内相关内容。
-
代理+缓存:
这个就比较高级了,结合了以上2者的特点,适合于超大规模的网站,一般用不到。
-
变种:
通过欺骗或者使用ip隧道技术使缓冲服务器代理或者访问本地的www服务器的方式达到访问目的。(主要通过修改本地主机信息)
负载均衡
-
基于域名的负载均衡:
原理类似于抽奖——准备多个IP,对应同一个域名。每做一次域名解析就随即返回一个IP,这无形中就等于将网站的访问量分摊给了多个主机,减少了单一节点的局限。具体判断方法是,nslookup命令返回的是多个ip地址
-
基于集群的负载均衡:
-
4层交换:
使用负载均衡技术建设高负载的网络站点
上次在加速LAMP一文的最后提到了负载均衡技术,这就是一篇关于负载均衡具体实现的理论分析。
Internet的快速增长使多媒体网络服务器,特别是Web服务器,面对的访问者数量快速增加,网络服务器需要具备提供大量并发访问服务的能力。例如 Yahoo每天会收到数百万次的访问请求,因此对于提供大负载Web服务的服务器来讲,CPU、 I/O处理能力很快会成为瓶颈。
简单的提高硬件性能并不能真正解决这个问题,因为单台服务器的性能总是有限的,一般来讲,一台PC服务器所能提供的并发访问处理能力大约为1000个,更 为高档的专用服务器能够支持3000-5000个并发访问,这样的能力还是无法满足负载较大的网站的要求。尤其是网络请求具有突发性,当某些重大事件发生 时,网络访问就会急剧上升,从而造成网络瓶颈,例如在网上发布的克林顿弹劾书就是很明显的例子。必须采用多台服务器提供网络服务,并将网络请 求分配给这些服务器分担,才能提供处理大量并发服务的能力。
当使用多台服务器来分担负载的时候,最简单的办法是将不同的服务器用在不同的方面。按提供的内容进行分割时,可以将一台服务器用于提供新闻页面,而另一台 用于提供游戏页面;或者可以按服务器的功能进行分割,将一台服务器用于提供静态页面访问,而另一些用于提供CGI等需要大量消耗资源的动态页面访问。然而 由于网络访问的突发性,使得很难确定那些页面造成的负载太大,如果将服务的页面分割的过细就会造成很大浪费。事实上造成负载过大的页面常常是在变化中的, 如果要经常按照负载变化来调整页面所在的服务器,那么势必对管理和维护造成极大的问题。因此这种分割方法只能是大方向的调整,对于大负载的网站,根本的解 决办法还需要应用负载均衡技术。
负载均衡的思路下多台服务器为对称方式,每台服务器都具备等价的地位,都可以单独对外提供服务而无须其他服务器的辅助。然后通过某种负载分担技术,将外部 发送来的请求均匀分配到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。由于建立内容完全一致的Web服务器并不复杂,可以使 用服务器同步更新或者共享存储空间等方法来完成,因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。
1.基于特定服务器软件的负载均衡(访问重定向)
很多网络协议都支持"重定向"功能,例如在HTTP协议中支持 Location指令,接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。由于发送Location指令比起执行服务请求,对 Web服务器的负载要小的多,因此可以根据这个功能来设计一种负载均衡的服务器。任何时候Web服务器认为自己负载较大的时候,它就不再直接发送回浏览器 请求的网页,而是送回一个 Locaction指令,让浏览器去服务器集群中的其他服务器上获得所需要的网页。
在这种方式下,服务器本身必须支持这种功能,然而具体实现起来却有很多困难,例如一台服务器如何能保证它重定向过的服务器是比较空闲的,并且不会再次发送 Location指令?Location指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环。因此这种方式实际应用当中并不多见, 使用这种方式实现的服务器集群软件也较少。有些特定情况下可以使用CGI(包括使用FastCGI或 mod_perl扩展来改善性能)来模拟这种方式去分担负载,而Web服务器仍然保持简洁、高效的特性,此时避免Location循环的任务将由用户的 CGI程序来承担。
2.基于DNS的负载均衡(多机单域名负载)
由于基于服务器软件的负载均衡需要改动软件,因此常常是得不偿失,负载均衡最好是在服务器软件之外来完成,这样才能利用现有服务器软件的种种优势。最早的 负载均衡技术是通过 DNS服务中的随机名字解析来实现的,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时得到其中的 一个地址。因此,对于同一个名字,不同的客户机会得到不同的地址,他们也就访问不同地址上的Web服务器,从而达到负载均衡的目的。
例如如果希望使用三个Web服务器来回应对www.exampleorg.org.cn的HTTP请求,就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果:
www1 IN A 192.168.1.1
www2 IN A 192.168.1.2
www3 IN A 192.168.1.3
www IN CNAME www1
www IN CNAME www2
www IN CNAME www3
此后外部的客户机就可能随机的得到对应www的不同地址,那么随后的HTTP请求也就发送给不同地址了。
DNS 负载均衡的优点是简单、易行,并且服务器可以位于互联网的任意位置上,当前使用在包括Yahoo在内的Web站点上。然而它也存在不少缺点,一个缺点是为 了保证DNS数据及时更新,一般都要将DNS的刷新时间设置的较小,但太小就会造成太大的额外网络流量,并且更改了DNS数据之后也不能立即生效;第二点 是DNS负载均衡无法得知服务器之间的差异,它不能做到为性能较好的服务器多分配请求,也不能了解到服务器的当前状态,甚至会出现客户请求集中在某一台服 务器上的偶然情况。
3.反向代理负载均衡(缓冲池)
使用代理服务器可以将请求转发给内部的Web服务器,使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术,让代理服务器将请求 均匀转发给多台内部Web服务器之一上,从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部Web 服务器,而这种代理方式是多个客户使用它访问内部Web服务器,因此也被称为反向代理模式。
实现这个反向代理能力并不能算是一个特别复杂的任务,但是在负载均衡中要求特别高的效率,这样实现起来就不是十分简单的了。每针对一次代理,代理服务器就 必须打开两个连接,一个为对外的连接,一个为对内的连接,因此对于连接请求数量非常大的时候,代理服务器的负载也就非常之大了,在最后反向代理服务器会成 为服务的瓶颈。例如,使用Apache的mod_rproxy模块来实现负载均衡功能时,提供的并发连接数量受Apache本身的并发连接数量的限制。一 般来讲,可以使用它来对连接数量不是特别大,但每次连接都需要消耗大量处理资源的站点进行负载均衡,例如搜寻。
使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能,具备额外的安全性,外部客户不能直接访问真实的服务器。并 且实现起来可以实现较好的负载均衡策略,将负载可以非常均衡的分给内部服务器,不会出现负载集中到某个 服务器的偶然现象。
4.基于NAT的负载均衡技术(内网cluster和四层交换)
网络地址转换为在内部地址和外部地址之间进行转换,以便具备内部地址的计算机能访问外部网络,而当外部网络中的计算机访问地址转换网关拥有的某一外部地址 时,地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址,此后外部网络中的计算机就各自与 自己转换得到的地址上服务器进行通信,从而达到负载分担的目的。
地址转换可以通过软件方式来实现,也可以通过硬件方式来实现。使用硬件方式进行操作一般称为交换,而当交换必须保存TCP连接信息的时候,这种针对OSI 网络层的操作就被称为第四层交换。支持负载均衡的网络地址转换为第四层交换机的一种重要功能,由于它基于定制的硬件芯片,因此其性能非常优秀,很多交换机 声称具备400MB-800MB的第四层交换能力,然而也有一些资料表明,在如此快的速度下,大部分交换机就不再具备第四层交换能力了,而仅仅支持第三层 甚至第二层交换。
然而对于大部分站点来讲,当前负载均衡主要是解决Web服务器处理能力瓶颈的,而非网络传输能力,很多站点的互联网连接带宽总共也不过10MB,只有极少的站点能够拥有较高速的网络连接,因此一般没有必要使用这些负载均衡器这样的昂贵设备。
使用软件方式来实现基于网络地址转换的负载均衡则要实际的多,除了一些厂商提供的解决方法之外,更有效的方法是使用免费的自由软件来完成这项任务。其中包 括 Linux Virtual Server Project中的NAT实现方式,或者本文作者在FreeBSD下对natd的修订版本。一般来讲,使用这种软件方式来实现地址转换,中心负载均衡器存 在带宽限制,在100MB的快速以太网条件下,能得到最快达80MB的带宽,然而在实际应用中,可能只 有40MB-60MB的可用带宽。
5. 扩展的负载均衡技术
上面使用网络地址转换来实现负载分担,毫无疑问所有的网络连接都必须通过中心负载均衡器,那么如果负载特别大,以至于后台的服务器数量不再在是几台、十几 台,而是上百台甚至更多,即便是使用性能优秀的硬件交换机也回遇到瓶颈。此时问题将转变为,如何将那么多台服务器分布到各个互联网的多个位置,分散网络负 担。当然这可以通过综合使用DNS和NAT两种方法来实现,然而更好的方式是使用一种半中心的负载均衡方式。
在这种半中心的负载均衡方式下,即当客户请求发送给负载均衡器的时候,中心负载均衡器将请求打包并发送给某个服务器,而服务器的回应请求不再返回给中心负载均衡器,而是直接返回给客户,因此中心负载均衡器只负责接受并转发请求,其网络负担就较小了。
这种方式的硬件实现方式也非常昂贵,但是会根据厂商的不同,具备不同的特殊功能,例如对SSL的支持等。
由于这种方式比较复杂,因此实现起来比较困难,它的起点也很高,当前情况下网站并不需要这么大的处理能力。
比较上面的负载均衡方式,DNS最容易,也最常用,能够满足一般的需求。但如果需要进一步的管理和控制,可以选用反向代理方式或NAT方式,这两种之间进 行选择主要依赖缓冲是不是很重要,最大的并发访问数量是多少等条件。而如果网站上对负载影响很厉害的CGI程序是由网站自己开发的,也可以考虑在程序中自 己使用Locaction来支持负载均衡。半中心化的负载分担方式至少在国内当前的情况下还不需要。
为 LAMP 加速
本技巧不仅仅可以为 PHP 提供加速的技巧,对于 Perl 和 Python 也有同样的效果。
为了得到完整的调试结果,建议你采用 ApacheBench 或者 httperf之类的软件。如果你对非 LAMP 架构的服务器测试有兴趣的话,建议你采用微软的免费软件: Web Application Stress Tool(需要 NT 或者 2000)。
检测 Apache ,采用 top d 1 显示所有进程的 CPU 和内存情况。另外,还采用 apachectl status 命令。
1、升级硬件的一般规则:对于 PHP 脚本而言,主要的瓶颈是 CPU ,对于静态页面而言,瓶颈是内存和网络。一台 400 Mhz 的普通奔腾机器所下载的静态页面就能让 T3 专线(45Mbps)饱和。
2、Apache 处理 PHP 脚本的速度要比静态页面慢 2-10 倍,因此尽量采用多的静态页面,少的脚本。
3、PHP 脚本如果不做缓冲,每次调用都需要编译,因此,安装一个 PHP 缓冲产品能提升 25-100% 的性能。
4、把基于文件的会话切换到基于共享内存的会话。编译 PHP 时采用 –with-mm 选项,在 php.ini 中设置 set session.save_handler=mm 。这个简单的修改能让会话管理时间缩短一半。
5、另外一项缓冲技术是把不常修改的 PHP 页面采用 HTML 缓冲输出。
6、如果你采用了 Linux 系统,建议升级内核到 2.6.0以上(现在最新版本为2.6.10)并开启抢占式内核支持,因为静态页面由内核服务。
7、采用最新版本的 Apache ,并把 PHP 编译其中,或者采用 DSO 模式,尽量不要采用 CGI 方式。
8、采用输出缓冲(请参考ob_start),如果你的代码有很多的 print 和 echo 语句,能提速 5-15% 。
9、不要在 Web 服务器上运行 X-Windows ,关掉没有必要运行的进程,如果已经安装了X-windows,请使用 init 3登录。
10、如果能够用文本就不要用图像,尽量减小图片的尺寸。
11、分散负载,把数据库服务器放到另外的机器上去。采用另外低端的机器服务图片和 HTML 页面,如果所有的静态页面在另外一台服务器上处理,可以设置 httpd.conf 中的 KeepAlives 为 off ,来减少断开连接的时间,但这样对于访问者来说不够友好。
12、采用 hdparm 来优化磁盘,一般能提升 IDE 磁盘读写性能 200%,但是对 SCSI 硬盘没有效果。
13、修改 httpd.conf :
# 关闭 DNS lookups,PHP 脚本只拿 IP 地址
HostnameLookups off
# 关闭 htaccess 检测
<Directory />
AllowOverride none
</Directory>
打开 FollowSymLinks ,关闭 SymLinksIfOwnerMatch 以防 lstat() 系统调用:
Options FollowSymLinks
#Options SymLinksIfOwnerMatch
下面还有很多关于 httpd.conf 参数的调整。
14、Kurt 简洁而完整的 Apache Tuning Tips。
15、如果喜欢从修改 Apache 源码入手,可以安装 lingerd。在页面产生和发送后,每个 Apache 进程都会浪费一段时光在客户连接上,Lingerd 能接管这项工作,让 Apache 迅速服务下一个客户请求。
16、如果网络拥挤,CPU 资源不够用,采用 PHP 的 HTML 压缩功能:
output_handler = ob_gzhandler
PHP 4.0.4 及以前的用户请不要使用,因为存在内存泄漏问题。
17、修改 httpd.conf 中的 SendBufferSize 为你最大的页面文件的大小。加大内核的 TCP/IP 写缓冲大小。
18、另外一篇文章:Tuning Apache Web Servers for Speed,一篇 97 年的很古老的文章。
19、采用数据库的持久连接时,不要把 MaxRequestsPerChild 设置得太大。
20、Caching Tutorial for Web Authors and Webmasters 教你怎样实现浏览器缓冲。
21、如果你足够勇敢的话,还可以采用 Silicon Graphics 的 Accelerated Apache 补丁。这个工程能使 Apache 1.3 快 10 倍,使 Apache 2.0 快 4 倍。
22、来自Professional Apache的技巧。
23、官方的Performance Tuning 文档,很好的资料,但是十分繁琐。
24、编译 PHP 时,建议采用如下的参数:
–enable-inline-optimization –disable-debug
25、安装mod_gzip(apache1.3)或者mod_deflate(apache2.0)等页面压缩软件减轻服务器拥堵。同时尽可能优化你的HTML文件和PHP文件。
26、优化 Linux ,more Linux 以及Solaris。
27、如果系统瓶颈在MYSQL的数据操作上,可以考虑将Mysql拆分成多个端口甚至多个服务器并适当优化my.cnf ,这比使用单个端口速度提高不少。
26、以上所有的方法都是针对单机而言的,如果你觉得系统还是不够快,可以采用集群,负载均衡,缓冲技术。采用 Squid 作为缓冲,配置 Squid 的方法。
FireFox的优化工具——firetune
Friefox最近的势头非常猛,不但几乎所有的linux的发行版都将其作为默认的浏览器,连windows平台下的Firefox的占有率也几乎一夜之间成为仅次于IE的第二大浏览器。
曾经看到过有篇介绍怎样优化friefox的帖子,其主要内容是在地址栏中输入“about:config",就会出现Firefox的隐含控制面板,对其作一系列的调整,比较麻烦也便于初学者掌握,于是就有这么一个工具面市,试用了一下,非常方便,不敢独享,提供给各位。
解包后运行FireTune.exe-〉选择"language"-〉chinese-gb.lng可选用简体中文界面。
一个IP建多个Web站点–主机头名法(apache篇)
首先,编辑httpd.conf文件,在尾部加上
NameVirtualHost *
编辑虚拟主机配置文件:
<VirtualHost *>
DocumentRoot "/htdoc" #html文件目录
ServerName test.com #虚拟主机名
ServerAlias *.test.com #做出响应的域名
##具体的目录配置
<Directory "/htdoc">
allow from all
</Directory>
DirectoryIndex index.php
</VirtualHost>
注意: ServerAlias 一栏,如果想让你的虚拟主机对应多个域名,可以将他们列出,并一一用空格隔开。
小窍门:
如果你同时管理多个虚拟主机,而且经常变动,那就可以在httpd.conf文件的末尾加上一句
include DIR/*.conf #DIR为你虚拟主机配置文件的目录
然后,将每一个虚拟主机的配置做一个单独的.conf文件,放在DIR目录下,到时候只要添加删除文件就可以了。
且谈google左侧排名
在网站推广方法中,搜索引擎推广是最重要的方法之一,而Google目前是世界最NB的搜索引擎了,占全球56%的搜索引擎市场,所以网站在Google 中的推广不可忽视。不过,目前大多网站在Google中的推广都是给Google钱,做Google右边的广告。 Google右侧广告虽然效果还凑合,但是价格毕竟太高了(每次点击,0.05美元),不是我们平常的网络老百姓能够承受了的。如何不给Google一分 钱在Google中更好的推广自己的网站呢?这里我教大家一套秘笈—- Google左侧排名。
Google左侧排名,主要是通过技术手段,提高网站在Google中的综合评分自然的获得较好的排名的。这里我们一下Google左侧排名技巧:
第一步:Google排名第一步要先了解Google排名的因素: Google排名因素据说超过300种,这个数据是一个国外的著名的SEO(搜索引擎优化研究)研究者提供的,不过我们必须研究那么深,因为我们祖先有句非常有道理的话是这么说的:万变不离其宗!
Google排名因素主要有以下几条:
A: 网站结构:合理的网站结构可以让Google轻松搜索到你网站的大多内容,收录你大量的页面,更多的关注你这个网站。是排名很重要的一条因素。
B: 标签设计:搜索引擎都喜欢通过一些标签来认识网页,判断网页,Google也不见外。此条因素也非常重要。
C: PageRank:也就是常说的PR值。Google对网页的等级评分。是排名因素中的重中之中,下面会给大家详细谈一下。
D: 网站流量:网站流量越大,Google越关注,而且不光对你网站更新非常快,而且对排名的好处也是非常大的。
E: 其他因素还有很多很多,这里就不列出来了,只要前面那四项我们想办法做好就OK。
第二步:优化网站:优化网站主要包括:网站结构优化,网站标签优化,网站页面优化,为的是让Google更容易搜索你的网站并且关注你想排的关键词。这里举个实际例子给大家谈:
A: 结构优化:让想GOOGLE收录你网站更多的网页,关键就是要让各个页面之间相互都有连接。另外最好再做一个详细的网站地图页面。
B: 标签设计:网页标签主要是两个标签,一个是网页标题,一个是简介标签,一个是关键词标签。标签中要适当的突出关键词。例如在Google中输入“电子商务”一次排名第一的网站首页标签是这么设计的:
.”>。
“>
这三段标签要放在与之间
注:标题标签长度不可超过40个字符(20个汉字)为好。
注:简介标签要清晰明了的写出网页简介内容,另外突出关键词。不要过长和写与网页内容不相干的内容
注:关键词标签写太多容易被认为作弊,老实写出就OK,不要写与自己网页无关的词。
C: 网页优化:
首页:许多网站首页都是纯FLASH或者是一个图片,这样结构的网站很不合理,首页是一个网站的入口,起到的主要就是导航作用。首页最好一个清晰明了又有内容的页面。
另外,网页文本内容中要突出关键词,里面遇到的关键词可以用加粗。另外文本中有其他页面的关键词的话,可以将这个关键词加上超链接,导向相关页面。
注:每个网页突出的关键词越少越好,最好不要超过3个。另外,网页中的关键词的密度一定要把我好一个度,不要太低,也不高太高。一般在3%左右比较合适。
第三步:提高网站的PR值. PR值是Google对网页的评分,主要根据网页之间的连接来计算:比如,A站有B站的连接,一个用户从A站点击B站在A站的连接进入B站,就表示A站投了B站一篇,将被GOOGLE记录。一个网页的外部连接越多,它的PR值就越高。
提高网页PR值主要有以下几中方法:
A: 和PR值高的网站做友情连接。
B: 登陆YAHOO, DMOZ 等许多网页目录。
C: 到一些自助连接站点登陆自己网站的连接。
D: 优化网站结构,让网站自身页面之间都有很好的连接。
第四步:提高网站流量:想让自己网站本身的流量越好越好,首先第一条就是要把网站自身内容做好,粘住浏览过你网站的客流,让他们第一次上你网站就记住你网站,并且下次需要相关信息了还会来你的网站。另外就是配合着做其他方面的推广。
Google左侧排名不给Google一分钱,而且如果左边排名达到后,效果是Google右侧广告效果的三十倍以上。还犹豫什么,赶快行动吧!
几款搜索引擎优化检测工具
Google链接广泛度检测器(Google Backlink Checker):
http://www.webconfs.com/google-backlink-checker.php 输入你的网站URL,程序将搜索到Google中有哪些网站链接了你的站点,以及链接所用的文本标题。由于不支持中文字符,中文文本内容是乱码,但链接的URL一目了然。
搜索引擎抓取内容模拟器(Search Engine Spider Simulator):
http://www.webconfs.com/search-engine-spider-simulator.php 输入你要查询的URL,获知Google可以抓取到的该页文本内容和链接。不妨对比测试一下使用大量文本和大量图片的页面所获得的内容悬殊的抓取结果。网络营销人也可以利用此工具来检测优化后的页面质量。支持中文字符。
搜索引擎抓取页面数量统计器(Search Engine Saturation):
http://www.marketleap.com/siteindex/ 输入你的网站URL和随机显示的进入代码,你将获得搜索引擎Alltheweb、AltaVista Google/AOL、HotBot/Inktomi所抓取到的你的网站页面数量。你也可以同时输入3个竞争对手网站URL以进行对比,了解自己在竞争中所处地位。
链接广泛度检测器(Link Popularity Check):
http://www.marketleap.com/publinkpop/ 输入你的网站URL和随机显示的进入代码,你将获知在搜索引擎Alltheweb AltaVista Google/AOL HotBot/Inktomi MSN 中有哪些网站链接了你的网站,以及同一URL在Dmoz、Excite、iWon、Lycos、Overture等搜索引擎中的详细链接资料。你也可以同 时输入5个竞争对手网站URL以进行对比,了解自己在竞争中所处地位。 同样的工具还有
http://www.trafficzap.com/linkpopularity.php ,可检测网站在Yahoo、Google、MSN、Lycos和Altavista的链接总数和具体链接的网站。 Google排名监测工具(Free Monitor for Google):
http://www.cleverstat.com/google-monitor.htm 需要下载使用。该工具可以报告你的网站以某关键词在Google中的排名情况,以及同一关键词下排名前N位(自己设定位数)的网站URL。
相似页面检测器(Similar Page Checker):
http://www.webconfs.com/similar-page-checker.php 众所周知,Google会对拷贝页面内容进行排名惩罚。该工具可以检验两个页面的相似度,来判断是否会受到惩罚。如
http://www.sitepronews.com/freebooks.html 和
http://www.allbusinessnews.com/freebooks.html ,相似度达到80%,后者在Google中的PageRank排名值通过工具栏显示为0.
中国顶级门户网站架构分析
某日上网,遇一强贴,正巧最近也在使用一些类似的技术实现我们公司的网站,现将其贴出。
首先声明,下面的内容都是我个人根据一些工具形成的猜想。并不保证和现实中各大门户网站所用的架构一摸一样,不过我认为八九不离十了。
新浪和搜狐在国内的知名度可谓无人不知无人不晓。他们每天的点击率都在千万以上。这样大的访问量对于新浪和搜狐来说怎样利用有限的资源让网民获得最快的速度成为首要的前提,毕竟现在网络公司已经离开了烧钱的阶段,开始了良性发展,每一笔钱砸下去都需要一定回响才行的。另一方面,技术人员要绞尽脑汁,不能让用户老是无法访问、或者访问速度极慢。这样就算有再好的编辑、再好的销售,他们也很难将广告位卖出去,等待他们的将是关门。当然这些情况都没有发生,因为他们的技术人员都充分的利用了现有资源并将他们发挥到了极至。说到底就是用squid做web cache server,而apache在squid的后面提供真正的web服务。当然使用这样的架构必须要保证主页上大部分都是静态页面。这就需要程序员的配合将页面在反馈给客户端之前将页面全部转换成静态页面。好了基本架构就这样,下面说说我怎么猜到的以及具体的架构:
法宝之一:nslookup
实战:
nslookup www.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.230, 61.172.201.231, 61.172.201.232, 61.172.201.233
61.172.201.221, 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229
Aliases: www.sina.com.cn, jupiter.sina.com.cn
这里可以看到新浪在首页上用到了那么多IP,开始有人会想果然新浪财大气粗啊。其实不然,继续往下看:
nslookup news.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.228, 61.172.201.229, 61.172.201.230, 61.172.201.231
61.172.201.232, 61.172.201.233, 61.172.201.221, 61.172.201.222, 61.172.201.223
61.172.201.224, 61.172.201.225, 61.172.201.226, 61.172.201.227
Aliases: news.sina.com.cn, jupiter.sina.com.cn
细心的人可以发现了news这个频道的ip数和首页上一样,而且IP也完全一样。也就是这些IP在sina的DNS上的名字都叫 taurus.sina.com.cn,那些IP都是这个域的A记录。而news,sports,jczs.news。。。都是CNAME记录。用DNS 来做自动轮询。还不信,再来一个,就体育频道好了:
nslookup sports.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229, 61.172.201.230
61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.221
Aliases: sports.sina.com.cn, jupiter.sina.com.cn
其他的可以自己试。好了再来看看sohu的情况:
nslookup www.sohu.com
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109
61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69, 61.135.150.74
61.135.150.75, 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80
Aliases: www.sohu.com
--------------------------------------------
nslookup news.sohu.com
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80, 61.135.132.172
61.135.132.173, 61.135.132.176, 61.135.133.109, 61.135.145.47, 61.135.150.65
61.135.150.67, 61.135.150.69, 61.135.150.74, 61.135.150.75
Aliases: news.sohu.com
情况和sina一样,只是从表面来看sohu的IP数要多于sina的IP数,那么sohu上各个频道用的服务器就要多于sina了?当然不能这么说,因为一台服务器可以绑定多个IP,因此不能从IP数的多少来判断用了多少服务器。
从上面这些实验可以基本看出sina和sohu对于频道等栏目都用了相同的技术,即squid来监听这些IP的80端口,而真正的web server来监听另外一个端口。从用户的感觉上来说不会有任何的区别,而相对于将web server直接和客户端连在一起的方式,这样的方式明显的节省的带宽和服务器。用户访问的速度感觉也会更快。
1. 难道就根据几个域名的ip相同就可以证明他们是使用squid的嘛?
当然不是,前面都只是推测。下面才是真正的证实我上面的猜测。先nslookup一把sina的体育频道。
nslookup sports.sina.com.cn
Server: ns1.china.com
Address: 61.151.243.136
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses:61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.9
61.172.201.10, 61.172.201.11, 61.172.201.12, 61.172.201.13, 61.172.201.14
61.172.201.15, 61.172.201.16, 61.172.201.17, 61.172.201.227, 61.172.201.228
61.172.201.229, 61.172.201.230
Aliases: sports.sina.com.cn, jupiter.sina.com.cn
然后直接访问这些ip中的任意一个ip试试看,访问下来的结果应该是如下图所示:
由此可以证明sina是在dns中设置了很多ip来指向域名sqsh-19.sina.com.cn,而其他各种相同性质的频道都只是sqsh- 19.sina.com.cn一个别名,用CNAME指定。dns的设置应该是这样的,然后server方面,通过squid 2.5.STABLE5(最新的稳定版为STABLE6)来侦听80端口。上面这些是根据一些信息分析而出的,应该基本正确的。下面一些就是我的个人的猜想:
它的真正的web server也同样是侦听80端口,因为在squid配置文件中有一项是:
httpd_accel_port 80
如果你设成其他端口号(比如88)的话,那上图的错误信息就会变成
While trying to retrieve the URL: http://61.172.201.19:88
工具2:nmap扫描程序:可以用来检查服务器开了什么端口。
我现在用nmap来扫描sina的一个ip:61.172.201.19来进行分析
bash-2.05$ nmap 61.172.201.19
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-07-30 13:31 GMT
Interesting ports on 61.172.201.19:
(The 1657 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nmap run completed — 1 IP address (1 host up) scanned in 73.191 seconds
可以看到他对外只开了2个端口,80端口就是刚才我们说的squid打开的,这点刚才已经验证过了。而22端口是用来ssh远程连接的,主要是sa用来远程操作服务器用的安全性非常高的方法。
工具3:lynx或者其他可以读取http头文件的工具及小程序:
直接看例子比较好理解:
HTTP/1.0 200 OK
Date: Fri, 30 Jul 2004 05:49:47 GMT
Server: Apache/2.0.49 (Unix)
Last-Modified: Fri, 30 Jul 2004 05:48:16 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Cache-Control: max-age=60
Expires: Fri, 30 Jul 2004 05:50:47 GMT
Content-Length: 180747
Content-Type: text/html
Age: 37
X-Cache: HIT from sqsh-230.sina.com.cn
Connection: close
上面是sina的http头的反馈信息。里面有很多有价值的东东哦:)譬如,它后面的apache是用2.0.49,还设了过期时间为2分钟。最后修改时间。这些都是要在编译apache的时候载入的,特别是Last-Modified还需要小小的改一把源码–至少我是这样做的。
综上所述
sina的架构应该是前面squid,按照现在的服务器2u,2g内存一般每台服务器至少可以跑4个squid2.5stable5. 这样它16个ip就用了4台服务器。后面一层是apache2.0.49应该会用2台。这2台可能用的全是私有ip,通过前面的squid服务器在 hosts文件中指定。具体的实现方法我会下次整理出我做实验的文档:)而apache的htdocs可能是有一个或2个磁盘阵列作nfs。apache mount nfs server的时候应该是只读的,然后另外还有服务器转门用来做编辑器服务器,用来编辑人员更新文章。这台服务器应该对nfs server是具有可写的权限。
—-这就一套完整的sina所运用的方案,当然很多是靠猜测的,我没有和sina的技术人员有过任何沟通(因为一个也不认识),否则我也就不会写出来了。其他sohu,163应该也有这样的架构。
最后声明:这只是一些静态页面组成频道的一个架构,sina还有很多其他服务器,什么下载,在线更新等不在这个架构中。


最近评论