WEB服务器性能瓶颈分析

本文先介绍一下各种WEB服务器平台，然后对影响WEB服务器性能的各方面做了分析，最后解析了目前使用最普遍的Apache服务器在服务请求高峰时的响应延迟现象

　 　在上周的一篇文章里，我们介绍了搭建WEB服务器的方法，但这只是建立WEB服务器的第一步，在实际的站点运行中，也许服务器的性能表现会不尽如人意， 这就需要分析具体的服务器性能瓶颈并找到解决办法。本文先介绍一下各种WEB服务器平台，然后对影响WEB服务器性能的各方面做了分析，最后解析了目前使 用最普遍的Apache服务器在服务请求高峰时的响应延迟现象，希望能对WEB服务器性能瓶颈的分析有所帮助。
　　


　 　对于互联网上的web平台，究竟有多少种不同的软硬件组合方式？你肯定会对这个数字感到吃惊。从配置了最新版本的IIS（Internet Information Server，因特网信息服务器）的WindowsXP系统到运行在Apache服务器上“古老”的SunOS 4.x系统，真是数之不尽。当然，最流行的几种平台也就那么几种。Windows NT类（尤其是同时配置了IIS和SQL Server的系统）是近来很常见的web平台。同时，运行在SUN公司SPARC工作站上的Solaris（安装了Netscape公司企业版的 Webserver）和免费的Apache服务器系统也比较常见。此外，令人相当吃惊的是，Linux和FreeBSD这两款开放源代码的顶级操作系统对 上述几类平台构成了巨大的威胁。正在改变服务器操作系统的分布格局。

为什么很多人选择Windows NT/2000/XP？

　　先撇开卓越的运行稳定性、系统正常稳定运行时间或表现等不论，Windows NT类操作系统在服务器应用环境领域占据的市场份额以惊人的速度持续快速增长，原因主要是，它具有非常体贴用户的易操作性及出类拔萃的开发工具。

　 　很多刚进入IT领域的用户非常喜欢Windows的这种“平民化”的界面，因为它极大地简化了日常的管理工作。对于开发人员来说，则因 Microsoft提供的目前最完整、最有效率的开发环境，而从NT系统中获益不小。类似InterDev的一些开发工具与Visual Source Safe（在庞大的工程中对软件版本进行管理）结合使用，能轻松地削减开发人员的开发时间。

为什么有的人不选择Windows NT？

　 　Windows NT毕竟仍属Windows家族的一员，也存在众多该系列操作系统所遭遇的问题，从而影响到一些运算量大、资源消耗多的应用程序的稳定性和可执行性。 Windows NT 4采用的是一个静态的内核，这就使得即使是执行一些非常简单的任务，比如装载一个新的驱动器，也必须重启机器。此外，和UNIX 相较而言，Windows NT还缺少大量的远程管理手段。不过,随着微软新版的服务器操作系统2000/XP的发布,这些问题正在得到解决,最新的WindwoXP服务器版可以说 是一个不错的服务器操作系统。
　　
关于Solaris

　　Solaris是UNIX操作系统在市场上最 流行的一种变体。互联网上大部分站点都采用Solaris提供web服务。在UNIX所有不同的变体中，Solaris拥有最大的用户群体，相应地，它也 是利润最丰厚的一款软件。各种应用服务器和应用环境专为Solaris设计的版本，比如ColdFusion（普遍使用在Windows NT上）均已推出。Solaris系统能够提供真实的企业级可靠性和高性能，其他平台很难与之媲美。与Windows NT不同的是，当你给系统添加额外的硬盘时，并不需要将Solaris系统重启。另外，在Sun公司更大型的企业级服务器上，你甚至能够在不关机的情况 下，更换内存条和CPU。与众多平台相比，Solaris还能提供最佳的多重处理（multiprocessing）性能。

为什么有人不愿意选择Solaris？
　　
　 　好了，为了公平起见，我来说说人们不选择Solaris的原因。先要指出的是，基于Intel芯片的Solaris平台不等同基于SPARC芯片的 Solaris平台。尽管Intel芯片版本的Solaris系统拥有与SPARC芯片版本一样的高可靠性，但用于前者的商用软件的数量明显不如后者多， 同时，由于硬件上的一些限制，Solaris系统的一些相对高级的特性（比如CPU或内存的热插拔升级）在Intel芯片版本中无法实现。前段时间甚至有 消息说最新的Solaris将不再支持Intel平台，这对采用Intel硬件平台的用户可说是一种遗憾。

选择Linux还是FressBSD？

　 　开放源代码操作系统(如Linux、FreeBSD)在市场上抢占着越来越大的市场份额，人们对这类系统的总体接受程度也开始以惊人的速度增长。几年 前，只有少数几家公司知道Linux到底是什么，但是目前它已被业界几乎每一个专业用户所大力推崇。举个例子，你可以在市场上买到更多的基于Linux平 台的商业软件，如Oracle、Sybase等等。

　　同时，FreeBSD也取得了相当一部分商业支持，其中一些是由于Linux流行 的原因而带来的。很多大型网站，比如Yahoo，跑的都是FreeBSD平台。FreeBSD和Linux之间的兼容性问题很小。因此，我们会发现，这两 款操作系统的用户群体将同步持续增长。

　　不幸的是，很多使用开放源代码操作系统的用户由于不希望缴纳相关的成本费用，实际上在抵制使用 Linux平台上的商业软件。从某个角度来看，仿佛是因为这些用户由于习惯了Linux系统免费使用的做法，而不愿意为服务器的其他应用付费。从目前情况 看，这已对市场产生了激冷效应。我估计，随着越来越多基于该平台的软件发布，这种情况将会更加恶化。

　　这主要是因为Linux操作系统大多是被小公司和个人所选用，而这类群体实际上根本买不起企业级的商业软件。这种状况只有在opensource操作系统的技术和市场成熟壮大起来，并被更多的大公司（他们往往拥有更大的需求）接纳之后才会逐渐改变。

　 　在互联网上，对开放源码操作系统支持的呼声很高，但是，人们对这类平台学习和理解的难度比Windows，甚或是Solaris要大得多。另外，所有的 这类软件均处在一个快速发展的过程中。所以，你在寻找你需要的东西的时候，也许总会不经意地发现系统的一些小bug（错误的计算机程序代码或例行程序上的 瑕疵）及不完整的软件包。

　　对于那些WEB服务需求小，硬件资源紧张的小公司来说，他们一般更愿意采用一款开放源码操作系统（而不采用 商业解决方案）。而对于缺少经验的公司来说，他们则倾向选择安全可靠的Windows解决方案。那些对Web 发布需求巨大，同时要求系统正常运行时间比率超过99%或以上的公司也许会选择Solaris平台。因为olaris的稳定性可以为满足这种苛刻的运行要 求提供更大保障。



　　一台提供web发布服务的服务器与其他大多数的常规主机相比较，被更宽泛的负载状态 （load conditions）所影响。事实上，一个web站点里能够容纳大量各种各样的内容，即使是其中一个简单的HTTP服务器（软件意义上的服务器），其负 载也远远超出了HTTP协议设计者当初所能预料的范围。

　　实际上，目前的web站点能够采用各种技术，包括静态HTML、内嵌或服务器 解析的HTML（inline/server-parsed HTML）和CGI（Common Gateway Interface，公共网关接口），并以ODBC（Open Database Connectivity，开放式数据库互接）实现数据库的互连。这些不同的数据源中有一部分非常普通，而其余部分却并非如此。不管如何，每一种数据源均 以其独特的方式在web服务中发挥着作用。在决定你的站点到底适合采用哪种服务器之前，你应该明确一下，你的需求究竟是什么。

静态HTML

　 　这是互联网上任何站点最基本的一种构成“元素”。尽管真正意义上完全采用静态HTML来搭建的站点数量越来越少，但是，几乎所有的站点均不同程度地采用 了这种“元素”。静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一个静态HTML文档发出访问请求 后，服务器端只是简单地将该文档传输到客户端。从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。为了提高静态HTML的访问效 率，主要可以对以下几个方面进行优化：网络带宽、磁盘I/O以及cache(高速缓冲存储器)。

服务器解析的HTML

　 　依靠服务器解析的HTML页面包括两部分的代码，一是标准的HTML代码，二是服务器端运行的代码（由第三方的处理程序或web服务器自己在页面传输到 客户端前对其进行解释）。这种HTML页面是CGI程序的升级版本（因为它的执行效率更高）。目前，内嵌的服务器端扩展集，比如ASP、PHP3，甚或是 普通的服务器端支持的扩展集，已得到了非常普遍的使用。开发这种扩展集的目的是要使网站上的内容更生动活泼，更模块化，以利于维护。此外，服务器解析文档 改善了性能相对低下的客户端工作模式，将客户端的负载降低到最低程度，同时也降低了数据传输对带宽的要求。很显然，你要得到这一切，就必须付出金钱的代 价。因为服务器解析文档必须在其传输到客户端前就通过服务器来进行解释，所以，你要给你的服务器添加额外的CPU。

公共网关接口（CGI）

　 　CGI使Web站点具有更佳的交互性和实用性。它可以用来收集用户的输入数据，允许运行外部程序以执行众多与用户输入相关的任务以及输出执行结果等，因 此，应用CGI后，互联网的用途被大大扩充了。但是，要使用CGI，就必须付出一定开销。特别在CGI与解释器（譬如PERL）配合使用时，CGI的调用 成本会很高。如果您的系统运行在极端繁重的负载条件下，该成本更是高居不下。如果可能的话，您应该考虑选用ASP或PHP3来取代CGI。

数据库的互连性

　 　目前，互联网上最大的资源杀手当非在线数据库（online databases）和电子商务（e-commerce）等应用莫属。提供web功能的数据库和应用服务器近年来飞速增长，显示出强劲的发展势头。从性能 的角度来看，在线数据库（基于Oracle、 SQL Server或 Sybase等）及应用如日中升，迫使人们更加关注服务器的性能状况。对于大型网站来说，高负载的HTTP传输和数据库处理事务互相抢占资源，并最终可能 导致服务器在极短的时间内崩溃或者变得慢如蜗牛。在这种情况下，推荐您使用专门的后台运行的数据库服务器（当然也是出于安全的考虑）以及前台处理的 HTTP服务器。



　　众所周知，究竟选用哪种不同类型的传输介质，必须根据预期的负载类型来决定。因此， 从这点来看，你应该可以粗略地决定究竟需要采用哪种硬件。尽管不同的平台提供不同的性能水平，各个平台的性能之间还是存在一定交迭的，因此，你可以在对需 要采用多少数量的硬件作任何决定之前，初步选择一下那些你使用起来最觉舒适的平台。

　　下文将那些与特定网站（这类网站一般只采用标准的传输介质和内容类型，如静态HTML、服务器解析文档以及从少量到数量适中的CGI程序）相关联的瓶颈根据其对系统的影响程度逐个列出。

　　网络带宽

　　吞吐量及高峰传输速率或突发传输速率（Spikes/Burst Transfer Rates）

　　内存

　　Webserver客户端和文件系统缓冲区（Filesystem Cache）占用的活动内存

　　存储

　　访问时间，跨多硬盘访问的效率

　　中央处理器

　　在多进程或多线程环境下的性能

　　网络带宽

　 　可用的带宽对于那些主要由静态页面构成的站点来说，也许是最关键的因素，但问题往往并不如你想象的那么简单。撇开网络的吞吐总量以及响应速度不讲，在高 负载的环境下，系统的突发传输速率是非常重要的。尽管通过单一的T1或T3传输速率提供的总带宽对一个特定的站点而言也许绰绰有余，但其最大的传输速率 （T1下为1.5mbit/s，T3下为4.5mbit/s）也可能不足以应付系统的高峰传输负载。在用户访问的高峰期，某些站点也许根本无法访问。这样 的站点在用户企图访问它时显得慢如蜗牛，而服务器自身却仍旧非常空闲。这样看来，要成功搭建一个web主机，考虑清楚你到底需要多大的带宽显然是非常重要 的。

　　内存

　　可用的物理内存是另外一个重要因素，这是因为对内存的占用率会直接随着对服务器请求数量 的增加而增加。计算分配给每个并发用户的内存数量以及并发用户的平均数量，只是你要考虑的事情中的一部分。文件缓冲区也是非常重要的，因为它能将磁盘的使 用频率降到最低程度，明显加快事务处理的总体速度。

　　对内存的需求很大程度上取决于使用在特定服务器上的软件的具体情况。除了操作系统的管理能力和文件系统的缓冲区大小之外，你还需要将你所选择的web服务器软件对硬件的特殊要求调查清楚。

　　存储

　 　和存储介质有关的读写时间指标也是非常重要的，对大型文件库和数据库（文件缓冲区的作用在这明显削弱）而言，尤其如此。在多设备协同工作的条件 下，Web服务器的磁盘系统必须有卓越的性能，推荐采用SCSI硬盘或RAID阵列。对于那些主要放开了“只读”权限的站点（用户不能上传数 据），RAID是最佳的解决方案。这是因为，在RAID阵列中存在多个硬盘磁头，能明显提升读取操作的数据吞吐量。

　　中央处理器

　 　对于那些主要由静态页面构成的站点来说，CPU只是你需要考虑的最次要的一个因素。这是因为，即便是一个非常低端的PC电脑也能充分发掘T1通道的传输 速率。但是，在使用了包括CGI、服务器解析文档或提供web访问方式的数据库的情况下，你需要更多地关注CPU的性能。在这种场合下，将事务处理速度和 并发处理性能两个概念分清楚是很重要的。如果你需要向一个较小的用户群体提供某种对CPU依赖很大的应用服务，那么，一个高速的单CPU可能是最有用的。 但是，如果存在多个用户同时对大批量的页面提出访问请求，那么在这种情况下（尤其在这些页面均以独立的进程或线程模式打开情况下），多CPU系统（即使这 些CPU的速度都很慢）也许更为管用。

分析服务器的工作模式

　　尽管在市场上可以购买到各式各样的Web服务器，但如果单就并发访问的处理方式来看，所有的服务器大体可以分成基本的四类。

　　Single-threaded模式（单线程模式）

　　非常有效，可充分提高资源效率（对称多处理机除外）

　　Fork模式（分叉模式）

　　每个请求的成本高，性能差，有良好的对称多处理特性

　　Pre-Fork模式（预分叉模式）

　　良好的对称多处理特性，响应速度通常比较快

　　Threaded模式（线程模式）

　　效率高的多处理特性，响应快　　

　　Single-Threaded模式

　　single-threaded 服务器通常采用选择的方法在单个进程中处理所有的访问请求。对只配置了一个处理器的机器来说，这类服务器是非常高效的。但是，它并不能通过增加额外的处理器来相应地提升性能。

　　在这次模拟测试中，我们在y轴标注的请求数量最大值为100条/秒，这是为了方便评估single-threaded 模式下的性能。模拟的服务器每秒处理的请求数量维持在70条，即便如此，这已和实际使用情况非常相近。我们发现，在该环境下，当处理较轻的负载时，single-threaded 模式是非常高效的，响应速度也非常迅捷。随着负载的增加，我们又发现，服务器的性能表现每况愈下，这种状况只能通过搭配更好的硬件才能改善。

　　Fork模式

　　通常来说，通过追加进程来处理每个请求的服务器由于多了一个增加新进程的环节，效率比较低下，响应速度也比较慢。由于通过这种方式在应付大批量的客户端请求时会过多地消耗资源，显然，随着请求数量和频率的增加，系统的性能将逐步下降。
　　
　　fork模式下的测试结果和single-threaded 模式下的测试结果非常相似。不同的是，由于每一个新进程的成本较高，相对于single-threaded 服务器来说，这种模式下的管理维护成本会随着http服务器进程的增加而增加。

　　Pre-Fork模式

　 　pre-fork服务器和fork服务器相似，也是通过一个单独的进程来处理每条请求。但是，不同的是，pre-fork服务器会通过预先开启大量的进 程，等待并处理接到的请求。由于采用了这种方式来开启进程，服务器并不需要等待新的进程启动而消耗时间，因而能够以更快的速度应付多用户请求。另 外，pre-fork服务器在遇到极大的高峰负载时仍能保持良好的性能状态。这是因为不管什么时候，只要预先设定的所有进程都已被用来处理请求时，服务器 仍可追加额外的进程。

　　pre-fork服务器相当独特的运行状态曲线。和先前提到的fork模式类似的是，pre-fork服务器也 是通过独立的http服务器进程来处理每一个请求，但是，和fork服务器不同的是，pre-fork服务器会随着请求数量的增加而启动若干新的进程。这 种方法的优点是，能在对http通讯保持一定响应能力的同时，给服务器提供少许的“喘息”时间。缺点是，当遇到高峰负载时，由于要启动新的服务器进程，不 可避免地会带来响应的延迟。

　　Threaded模式

　　threaded服务器和http服务器（对每一请求都必须生成新的进程来处理）有些类似。但是，它由于采用了线程技术，一般能以更低的管理成本取得用进程来处理请求的效果。
　　
　　threaded服务器和通过生成新的进程来处理请求的服务器差别不大，只是它生成的是线程而不是进程，因此，它对资源的依赖性也比较小。



　　目前世界上最流行的Web服务器非Apache莫属。它采用的是Pre-Fork模式。让我们看看它是怎么工作的。

　　Apache的Pre-Fork服务器设计的原理是：当闲置的服务器进程数量小于用户预设的阀值时就启动额外的进程。另一用户设定的变量则决定空闲的服务器进程的最大数量，同时，如果实际闲置的进程数量超过这个最大值，服务器就会将空闲的进程关闭。

　　为了顺利完成以下的模拟测试，我们先假定以下几个条件：

　　1、空闲的服务器进程数量的最小值为5

　　2、空闲的服务器进程数量的最大值为10

　　3、服务器进程数量的初始值为5
　　
　 　当Pre-Fork服务器在一个“无限机”上的运行状态（这台机器拥有无穷大的物理内存和CPU时间，我们姑且假定它是真实存在的）。Pre-Fork 服务器在遇到高峰负载时产生的“步阶”（stair-step）效应。实际上，在这种情况下，由于之前假定Pre-Fork服务器拥有无限的资源，所以它 的性能表现非常令人满意。但是，随着时间的推移，实际性能却能通过修改基于平均负载活动的服务器进程数量的最大和最小值而发生变化。

　　当然，这台拥有无限资源的机器显然是不存在的，因此，让我们在做一个比较真实一些的模拟测试。这次，我们要把物理内存的使用情况考虑进去。姑且作以下假定：

　　1、空闲的服务器进程数量的最小值为5

　　2、空闲的服务器进程数量的最大值为10

　　3、服务器进程数量的初始值为5

　　4、这台机器配置了256 MB的物理内存。将操作系统和文件系统缓冲区因素考虑进去的话，我们假定其中有196MB的内存单独供web服务器使用。

　　5、每一web服务器进程消耗1.5 MB的物理内存

　　6、不考虑CPU和硬盘因素，同时，我们假定一旦机器的内存耗竭，就无法再处理额外的访问请求。

　 　这次测试表明，在机器所有物理内存被庞大的高峰负载消耗殆尽之前，我们这台更真实的服务器的性能表现和那台拥有无限资源的理想服务器是完全一样的。可用 的物理内存数量（单位：MB）用红线在图中标示，并发请求数量达到130条时，内存就被耗光。这使得320个请求处于未响应状态。如果我们将CPU的使用 率和磁盘活动等因素考虑进去的话，这些数字将会更小，机器为应付缺少可用内存的状况而忙于将数据在内存与硬盘之间交换，这显然会降低系统的性能。
　　


　 　正如你所知道的，影响web服务器性能的因素数之不尽，要限制这些因素发挥作用，只能充分发挥人们的创造性思维。用来发布不同类型页面的Web系统对硬 件的要求也是不一样的。本文只是粗略地介绍了搭建一个Web服务器要考虑的因素，我希望它能帮助你更好地去理解这些系统要求。在这个基础之上，今后，我们 还将发表一些文章，介绍一下在Web服务器环境下的Athlon系统、对称多处理（SMP）系统以及它们在Web环境下的性能表现。

 

 

Quote: http://www.it.oaod.com/PcTech-34683.html