您的位置: 网界网 > 周报全文 > 正文

[周报全文]诊断Web系统

2004年04月26日 00:00:00 | 作者:佚名 | 来源:$page.getBroMedia() | 查看本文手机版

摘要:诊断Web系统

标签

    诊断Web系统

    ■ 《网络世界》评测实验室 于洋

    遇到过这样的情况:使用性能监视器查看Web服务器资源的使用情况,发现CPU占用率30%,4G内存尚有一半多的剩余,网络带宽的利用率在5%左右,数据库服务器仅有少量的查询操作,可是此时Web系统给人的感觉却是不堪重负,TCP和HTTP层面上均有大量丢包,问题出在哪里?

    有的读者可能会说,你还没有对磁盘的性能进行考核,是不是产生了太多的磁盘分片,导致读写延迟增大。是的,在整个Web系统中,CPU、内存、磁盘、网络都有可能成为瓶颈。如果有数据库的话,千万也别放过这个环节。套用一句话来形容:凡是有可能成为瓶颈的地方,就一定会成为瓶颈。不过,大家的Web系统应用情况各有不同,因此诊断结果也会因人而易。

    影响因素:硬件

    有一个导致服务器不能正常工作的原因就是缺少内存。这可能导致所有的进程都转移到硬盘上去运行。这时系统性能会严重下降,用户在可接受的时间内得不到请求页面的内容。一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断地扫描内存,将内存中的页面移到硬盘上,同时也加大了硬盘的负担。这种情况下,更换更快的CPU或磁盘是没有用的,您必须增加内存或想办法减少内存的使用。

    动态页面特别是像JSP这样的网页最终产生HTML网页的时间要比网页从网卡传出的时间长,要耗费更多的CPU资源。据CNNIC的调查,全国访问量前百名网站的动态页面占总页面的比例不过10%左右,中小网站的动态页面比例则远高于这个数字。

    硬盘的读取也是页面访问的环节之一,应尽量选用快速硬盘。而且,花同样的价钱买多个小硬盘,然后以RAID的配置方式让它们一起工作,比仅仅使用一个大的硬盘会有更好的可用性和性能。因为它们在物理上比较小,通常查询时间也短。RAID系统还可以并行运行多个请求。硬盘格式化的方式以及卷大小的设置都会对系统产生影响。

    网卡支持的带宽越来越高,不过网卡的缓冲区大小也值得关注,缓冲区小比较容易发生缓冲区溢出和丢失连续数据,这样会导致TCP数据的重传,增加了系统开销。

    很多时候,仅仅增强某种硬件不能解决问题。比如高性能的CPU常被低速的总线浪费了。大多数进程被划分为两类:I/O-bound(输入/输出限制)和CPU-bound(CPU限制)。对于静态网页来说,常常是I/O-bound。如果被请求页面不在内存中,那么检索文件的速度受到硬盘读取速度的限制,该页面从网卡传出时受到网卡速度的限制。硬盘和网卡都是I/O设备,它们比CPU要慢许多,所以CPU能力在此时的影响并不明显。因此,对站点工作方式的分析对选择服务器硬件是很必要的。

    影响因素:软件

    有很多调优工作是在“软”的基础上进行的,这部分工作主要体现在Web服务器软件、操作系统和后台数据库及网站的程序设计上。

    拿Web服务器软件来说,比如Apache,实际应用中要根据用户访问情况对有些默认参数进行调整。最大用户数与服务器进程数相关联,它们和内存是一对矛盾。一方面,我们希望服务器支持的并发用户能多一些,但又不能把httpd(HTTP daemon)进程数设置的过高,如果内存不足以处理服务器进程,那么就会发生交换,每个进程的性能就会下降。在这个问题上,要遵循的原则就是在只利用内存就能够处理众多的服务器进程。做这方面的规划,离不开对进程、线程占用内存的评估。这对于不同的Web服务器软件来说是不同的,有时也需要对操作系统的核心参数进行调整。

    后台数据库的规划和优化内容非常丰富。可以说,数据库有更多的理由成为整个Web系统的瓶颈。不良的SQl语句会降低性能,I/O、共享池区、数据库缓冲区高速缓存的设置也都影响着数据库的表现。

    此外,可能只有一种方式能使代码最有效的运行,但拖后腿的糟糕的代码写法却有千百种,有些网站的程序停留在功能可用的层次上,一旦访问量到达一定的高度,程序不必要地吞噬过多系统资源的缺点就会暴露出来。

    发现瓶颈

    各种操作系统都有相应的手段查看CPU、内存、网络等使用情况的工具。结合这些监测工具,采用测试仪或自己定制一些脚本对其中的每一部分进行测试,能比较客观地分析出各种因素对于Web系统的影响到底是怎么样的。

    测试方法的确定是整个测试中最为重要的一环。对于想优化现存系统的用户来说,方法意味着正确模拟现有环境,找到瓶颈所在。虽然任何一种系统的测试方法都不是清规戒律,但一般都会有通用的指导原则。测试方法至少包括:量度,测试内容或分类,测试工具的部署(主要是建立脚本模拟相应流量模型)。对于Web系统来说,从浏览器一方来看,需要考察的内容包括:最大并发用户数,连接建立时间和响应时间,单位时间内处理的HTTP交易数目等。如果综合连接建立时间和响应时间两项数据,它更能体现用户的感受。像我们常说的8秒规则,一个页面8秒内不能显示给网民的话,那此人就有可能和这个网站说再见了。从服务器一方来看,网站管理员希望网站在正常响应用户请求的前提下(+微信关注网络世界),系统资源占用尽可能少,或者说合理。这些系统资源包括:CPU、内存、磁盘等。确定了考察的量度,来看看Web系统测试的若干分类。

    基准性能测试:测试时仅使用一个用户,观察在此最简条件下Web系统的响应时间和资源占用情况。通常,一个有经验的开发人员在网站开发完毕后能够对单用户访问情况做大概的预测。如果遇到太离谱的性能数据,可能是某个组件的设计出了问题。在进行大规模的压力测试之前,这些问题应该先解决掉。

    特定负载下的测试:这种测试的目的是要模拟实际的使用,对于商业网站来说,中小企业的网站和大型门户网站对软硬件的要求是不同的,因此如果能够贴切地模拟出真实的用户访问,对于企业来说,可以指导投资进行原始采购,也可以帮助找出现存瓶颈。

    过载测试:这样的测试在操作时一定要让系统达到极限,此时考察系统无法承受如此大的访问量时的行为。比如说,系统是拒绝新的访问请求,还是殃及大批现有连接,甚至网站干脆瘫痪。关于Web系统的过载,有一种定义是“活锁”的发生:当我们使用测试仪向Web系统施加足够大的压力时,可以在测试进程报告中发现,尽管Client端发出的TCP建立请求均被服务器成功响应,但由于TCP/IP协议栈的调度优先级高于处于用户级别的Web服务器软件,这时CPU已经没有空闲,HTTP包被丢弃,尽管没有死机,却也不能处理更多业务层面上的请求。

    可靠性测试:进行这种测试很关键的一点就是要选用合理的流量模型,使用极限流量加长时间一般来说没什么意义,模拟真实的访问情况更有参考价值。如果在一段比较长的时间内,网站能够在某一特定的响应时间级别上正常运行,我们就可以认为它在实际应用中是可靠的。

    对于测试结果的分析要费一番力气。有时,各种性能数据掺杂在一起具有一定的欺骗性,要找到Web系统真正的病因,必须面对类似磁盘I/O性能的低水平是否源于内存缺乏这样的问题。否则,对新硬件的投资一定会让你失望。

[责任编辑:程永来 cheng_yonglai@cnw.com.cn]