首页 > 知识点讲解
       故障分析
知识路径: > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 结果评估与测试报告 > 
相关知识点:23个      
        这里主要讨论故障分析内容以及优化调整设置内容,同时还与读者分享故障分析的经验与实例。
               故障分析重点内容
               故障分析的重点内容包括以下几个方面:
               ①CPU问题。
               ②内存和高速缓存。
               ③磁盘(I/O)资源问题。
               ④配置参数。
               ⑤应用系统网络设置。
               ⑥数据库服务器故障定位。
               经验探讨
               . 经验举例1。
               交易的响应时间如果很长,远远超过系统性能的需求,表示耗费CPU的数据库操作。例如排序,执行aggregate functions(例如sum、min、max、count)等较多,可考虑是否有索引以及索引建立得是否合理。尽量使用简单的表链接、水平分割大表格等方法来降低该值。
               . 经验举例2。
               测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器,这样,就可以在Web端测出的响应时间减去以上各个分段测出的时间,就可以知道瓶颈在哪里并着手调优。
               . 经验举例3。
               UNIX资源监控(NT操作系统同理)中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈,也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。
               . 经验举例4。
               UNIX资源监控(NT操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。合理使用的范围在60%~70%。
               . 经验举例5。
               Tuxedo资源监控中指标队列中的字节数(Bytes on queue),队列长度应不超过磁盘数的1.5~2倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。
               . 经验举例6。
               SQL Server资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。注意该参数值是从SQL Server启动后,就一直累加记数,所以运行经过一段时间后,该值将不能反映系统当前值。
               优化调整设置
               针对上述故障分析的重点内容,需要做相应的优化调整,建议如下。
               . CPU问题。
               ①考虑使用更高级的CPU代替目前的CPU;
               ②对于多CPU,考虑CPU之间的负载分配;
               ③考虑在其他体系上设计系统,例如增加前置机、设置并行服务器等。
               . 内存和高速缓存。
               ①内存的优化包括操作系统、数据库、应用程序的内存优化;
               ②过多的分页与交换可能降低系统的性能;
               ③内存分配也是影响系统性能的主要原因;
               ④保证保留列表具有较大的邻接内存块;
               ⑤调整数据块缓冲区大小(用数据块的个数表示)是一个重要内容;
               ⑥将最频繁使用的数据保存在存储区中。
               . 磁盘(I/O)资源问题。
               ①磁盘读写进度对数据库系统是至关重要的,数据库对象在物理设备上的合理分布能改善性能。
               ②磁盘镜像会减慢磁盘写的速度。
               ③通过把日志和数据库对象分布在独立的设备上,可以提高系统的性能。
               ④把不同的数据库放在不同的硬盘上,可以提高读写速度。建议把数据库、回滚段、日志放在不同的设备上。
               ⑤把表放在一块硬盘上,把非簇的索引放在另一块硬盘上,保证物理读写更快。
               . 调整配置参数。
               ①包括操作系统和数据库的参数配置。
               ②并行操作资源限制的参数(并发用户的数目、会话数)。
               ③影响资源开销的参数。
               ④与I/O有关的参数。
               . 优化应用系统网络设置。
               ①可以通过数组接口来减少网络呼叫。不是一次提取一行,而是在单个往来往返中提取10行,这样做效率较高。
               ②调整会话数据单元的缓冲区大小。
               ③共享服务进程比专用服务进程提供更好的性能。
               负载压力典型问题分析
               负载压力测试需要识别的故障问题主要包括:
               . 非正确执行的处理。
               . 速度瓶颈与延迟。
               . 不能达到满意服务水平。
               . 接口页面不能正确地装载或者根本不能装载。
               当在合理的加载下出现这些类型的问题时,则表示可能有基础性的设计问题,比如说:算法问题,低效的数据库应用程序交互作用等,这些都不是通过简单升级硬件以及调整系统配置就可以解决的问题,此时软件的故障定位和调优将占有更重要的地位。
               Web网站故障分析举例
               目前Web开发者开始提供可定制的Web网站,例如,像搜索数据之类的任务,现在可以由服务器执行,而无需客户干预。然而,这些变革也导致了一个结果,这就是许多网站都在使用大量的未经优化的数据库调用,从而使得应用性能大打折扣。
               我们可以使用以下几种方法来解决这些问题:
               . 优化ASP代码。
               . 优化数据库调用。
               . 使用存储过程。
               . 调整服务器性能。
               优秀的网站设计都会关注这些问题。然而,与静态页面的速度相比,任何数据库调用都会显著地影响Web网站的响应速度,这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。
               这里提出的性能优化方案正是基于以下事实:访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是:在用户访问页面之前,预先从数据库提取信息,写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据,必须有一个调度程序管理静态页面的生成。
               当然,这种方案并不能够适应所有的情形。例如,如果是从持续变化的大容量数据库提取少量信息,这种方案是不合适的。
               每当该页面被调用时,脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值,更新脚本就会运行,否则,该ASP页面把余下的HTML代码发送给浏览器。
               如果每次访问ASP页面的时候都要提供最新的信息,或者输出与用户输入密切相关,这种方法并不实用,但这种方法可以适应以固定的时间间隔更新信息的场合。
               如果数据库内容由客户通过适当的ASP页面更新,要确保静态页面也能够自动反映数据的变化,我们可以在ASP页面中调用Update脚本。这样,每当数据库内容改变时,服务器上也有了最新的静态HTML页面。
               另一种处理频繁变动数据的办法是借助Microsoft SQL Server 7.0或以上版本的Web助手向导(Web Assistant Wizard),这个向导能够利用Transact-SQL、存储过程等从SQL Server数据生成标准的HTML文件。
               Web助手向导能够用来定期地生成HTML页面。正如前面概要介绍的方案,Web助手可以通过触发子更新HTML页面,比如在指定的时间执行更新或者在数据库数据变化时执行更新。
               SQL Server使用名为sp_makewebtask的存储过程创建HTML页面,它的参数是目标HTML文件的名字和待执行存储过程的名字,查询的输出发送到HTML页面。另外,也可以选择使用可供结果数据插入的模板文件。
               万一用户访问页面的时候正好在执行更新,我们可以利用锁或者其他类似的机制把页面延迟几秒钟。
               我们对纯HTML加调度ASP代码和普通的ASP文件进行了性能测试。普通的ASP文件要查找5个不同的表为页面提取数据。为了和这两个文件相比较,对一个只访问单个表的ASP页面和一个纯HTML文件也进行了测试。测试结果如下表所示。
               
               加调度ASP代码和普通ASP代码测试对比
               其中TTFB是指“Total Time to First Byte”, TTLB是指“Total Time to Last Byte”。
               测试结果显示,访问单个表的ASP页面的处理时间是720.5ms,而纯HTML文件则为427ms。普通的ASP文件和纯HTML加调度ASP代码的输出时间相同,但它们的处理时间分别为3633.67ms和1590ms。也就是说,在这个测试环境下我们可以把处理速度提高43%。
               如果我们要让页面每隔一定的访问次数进行更新,比如100次,那么这第100个用户就必须等待新的HTML页面生成。不过,这个代价或许不算太高,其他99个用户获得了好处。
               静态页面方法并不能够适合所有类型的页面。例如,某些页面在进行任何处理之前必须要有用户输入。但是,这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面,而且这种情况下它将发挥出更大的效率。
               在大多数情况下,动态页面的生成将在相当大的程度上提高网站的性能,而且无须在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能,但也有许多网站完全由于进行大量没有必要的数据库调用,而表现出很差的性能。
 
 相关知识点:
 
软考在线指南
优惠劵及余额
在线支付
修改密码
下载及使用
购买流程
取消订单
联系我们
关于我们
联系我们
商务合作
旗下网站群
高级资格科目
信息系统项目管理师 系统分析师
系统架构设计师 网络规划设计师
系统规划与管理师
初级资格科目
程序员 网络管理员
信息处理技术员 信息系统运行管理员
中级资格科目
系统集成项目管理工程师 网络工程师
软件设计师 信息系统监理师
信息系统管理工程师 数据库系统工程师
多媒体应用设计师 软件评测师
嵌入式系统设计师 电子商务设计师
信息安全工程师
 

本网站所有产品设计(包括造型,颜色,图案,观感,文字,产品,内容),功能及其展示形式,均已受版权或产权保护。
任何公司及个人不得以任何方式复制部分或全部,违者将依法追究责任,特此声明。
本站部分内容来自互联网或由会员上传,版权归原作者所有。如有问题,请及时联系我们。


工作时间:9:00-20:00

客服

点击这里给我发消息 点击这里给我发消息 点击这里给我发消息

商务合作

点击这里给我发消息

客服邮箱service@rkpass.cn


京B2-20210865 | 京ICP备2020040059号-5 |京公网安备 11010502032051号 | 营业执照 | Copyright ©2000-2023 All Rights Reserved 软考在线版权所有