性能测试结果分析

性能测试结果分析 分析原则: 具体问题具体分析(这是由于不同的应用系统，不同的测试目的，不同的性能关注点) 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈-〉网络瓶颈(对局域网，可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置，数据库，web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等) 注:以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下，系统的硬件瓶颈在哪儿就够了。 分段排除法 很有效 分析的信息来源: 1)根据场景运行过程中的错误提示信息 2)根据测试结果收集到的监控指标数据 一(错误提示分析 分析实例: 1)Error: Failed to connect to server “payment.baihe.com″: [10060] Connection Error: timed out Error: Server “user.baihe.com″ has shut down the connection prematurely 分析: A、应用服务死掉。 (小用户时:程序上的问题。程序上处理数据库的问题) B、应用服务没有死 (应用服务参数设置问题) 例:在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25, C、数据库的连接 (1、在应用服务的性能参数可能太小了;2、 数据库启动的最大连接数(跟硬件的内存有关)) 2)Error: Page download timeout (120 seconds) has expired 分析:可能是以下原因造成 A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多 C、在程序处理 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 的时候检查字段太大多 二(监控指标数据分析 1(最大并发用户数: 应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。 在 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。 如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2(业务操作响应时间: 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的,问题是否与网络或服务器有关, 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题 2-5-10原则:简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快;当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可 以;当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受;而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者 认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求 3(服务器资源监控指标: 内存: 1)UNIX资源监控中指标内存页交换速率(Paging rate)，如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。 2)Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。 内存资源成为系统性能的瓶颈的征兆: 很高的换页率(high pageout rate); 进程进入不活动状态; 交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率; 内存不够出错(out of memory errors) 处理器: 1)UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization)，如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。 2)Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率(Processor Time)一直很低，则存在着处理器阻塞。 CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time) CPU空闲时间为零(zero percent idle CPU) 过高的用户占用CPU时间(high percent user CPU) 过高的系统占用CPU时间(high percent system CPU) 长时间的有很长的运行进程队列(large run queue size sustained over time) 磁盘I/O: 1)UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate)，如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。 2)Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。 I/O资源成为系统性能的瓶颈的征兆 : 过高的磁盘利用率(high disk utilization) 太长的磁盘等待队列(large disk queue length) 等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 太长的运行进程队列，但CPU却空闲(large run queue with idle CPU) 4(数据库服务器: SQL Server数据库: 1)SQLServer资源监控中指标缓存点击率(Cache Hit Ratio)，该值 越高越好。如果持续低于80%，应考虑增加内存。 2)如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高， 则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优 化。 3)Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。 4)Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。 Oracle数据库: 1)如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。 2)如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS 参数的值(单位:块)。 3)如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。 4)如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。 讨论: 最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案 一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略) 一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本) 还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案? 总的来说这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求。 如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现; 如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现; 那么，你只要集群的服务器足够多，10万并发数当然可以达到了。 通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。 还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢, 这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时 在线用户转换到并发数的比例。 另外根据经验统计，对于1个JAVA开发的WEB系统(别的我没统计过，给不出数据)， 一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个(这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义)，可正常使用(单步非大数据量操作等待时间不超过20秒)的最大并发数不超过300个。 假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。 当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 套用1句经典台词“高，实在是高” 另外暴寒1下，你的设置光全部进入运行状态就需要接近6个小时。 具体的你可以拿1个系统来压一下看看，可能会出现以下情况: 1。服务器宕机; 2。客户端宕机; 3。从某个时间开始服务器拒绝请求，客户端上显示的全是错误; 4。勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度; 另外以上分析全都没考虑系统的后台，比如数据库、中间件等。 我从没遇到你说的这样的性能需求过，也只好凭感觉随便掰掰: 1。服务器方面:上面说的那样的PC SERVER需要50台; 2。网络方面:按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的; 3。如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器; 4。如果有CORBA，那至少再准备10台4CPU、16G内存的机器; 再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。 呵呵。精彩。向jackie和robust学习哦。 不过对于LZ说的这样的门户系统，由于有用户权限，所以并不象jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过1台机器的测试结果来计算多台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在1台机器上变化，那我们只能做一些指标上的计算，可以从这些指标上简单判断一下是否不可行。 比如10万并发用户却只有1根百兆带宽，那我们可以计算出每个用户只有1K带宽，这显然是不可行的。但实际的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。 另外我也解释一下为什么说“这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求”。 这一类是指最大并发数、最大在线用户数量等。因为用户操作不同功能，对系统的压力就不同，而在实际使用过程中常常会出现因为时间不同或者发生突发事件导致整体用户操作上功能的变化。 所以没有统一的功能使用的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 导致了这一类的指标成了个噱头。所有的软件厂商都是自说自话，把自己的软件安装在一个极端的环境中，做一些没有实际意义的操作，得出一个你永远都不可能达到的性能指标出来。 就如同汽车厂商的汽车油耗一样，反正你就听听罢了，真正使用中是不算数的。 另外这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大(当然不完全排除后期针对某些代码和配置进行优化后性能的进一步提高)，更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器等。 ============================== 常识: 网络技术中的10M 带宽指的是以位计算, 就是 10M bit /秒 ,而下载时的速度看到的是以字节(Byte)计算的,所以10M带宽换算成字节理论上最快下载速度为: 1.25 M Byte/秒! =============================== 服务器性能指标 通用指标 ProcessorTime 服务器CPU占用 Memory Available Mbyte 可用内存数 Physicsdisk Time 物理磁盘读写时间情况 Web服务器指标 Requests Per Second: 平均每秒钟响应次数,总请求时间/秒数 Successful Requests: 成功的请求 Failed Requests : 失败的请求 Successful Hits : 成功的点击次数 Failed Hits : 失败的点击次数 Hits Per Second : 每秒点击次数 Successful Hits Per Second:每秒成功的点击次数 Failed Hits Per Second : 每秒失败的点击次数 数据库服务器性能指标 User Connections :用户连接数 Number of deadlocks:数据库死锁 Butter Cache hit :数据库Cache的命中情况 通俗理解: 日访问量 常用页面最大并发数 同时在线人数 访问相应时间 =============================== 转自天外浪子的博客