搜索
7点测试：Zee整体目录可用性统计分析性能测试执行、控制及分析排队论在分析过程中的应用性能测试需求的获取和分析性能问题实例理解性能测试分析一下频繁GC的现象测试场景资源监控测试方法典型业务和比例测试数据理解模型满意的用户？不满意的用户？•连续性风险•长时间•多用户•峰值•最大并发量•系统性能拐点性能测试优化分析理解性能分析性能问题它可以是时间，可以是资料，也可以是业务！客户集中测试环境ApplicationA北京ApplicationBApplicationC上海广州WebServer从不同的地区浏览项目基于浏览器方式来执行一个或者多个性能测试项目ABC接收测试数据和分析结果性能实施和控制应用InterfaceTesting1Testing2Testing3TestingnMonitorSchedulerMulti-APPsupport理解性能监控数据库应用服务器CPU磁盘内存CPU磁盘内存性能分析路径整体目录可用性统计分析性能测试执行、控制及分析排队论在分析过程中的应用性能问题实例性能测试需求的获取和分析理解性能测试核心业务业务Ａ业务Ｂ说明容量测试关注的性能指标最大处理能力（TPS）成功率幵发用户在线用户每秒点击率（HPS）响应时间吞吐量资源阀值综合场景单负载基准测试Web服务器应用服务器中间件数据库网络HA•99%以上（建议）•各类资源稳定使用•合理释放资源•系统运行特性•用户总量•压力的大小•业务配比•多场景模拟压力场景运行时间成功率资源释放稳定性能力评估目标00:0003:0006:0009:0012:0015:00…….50%70%160%230%100%150%380%300%XX日测试目的来源：1.业务人员；2.开发人员；3.客户需求；内容：1.描述环境（软硬件、条件）；2.描述业务；3.描述性能指标；4.描述数据；5.描述测试策略；测试范围项目背景系统架构说明系统拓扑说明测试范围说明交易路径描述需要测试的特性不需要测试的特性业务调研系统类型：系统的基本特性，如交易处理型系统、数据处理型系统等架构部署：系统的整体架构、服务器部署方式技术信息：系统运行平台、数据库产品、使用的中间件、协议及通讯方式等业务信息：支持的业务类型、业务范围不功能、不其它系统的业务关系等系统信息调研基本业务不功能：系统的基本业务概念以及系统的业务种类不具体功能关键业务逻辑不处理流程：关键业务的业务流程、交易路径、交易数据、交易流程不时序图交易列表：调查业务系统全部交易清单，了解交易的组合关系、执行顺序等交易量信息：在丌同时间粒度下统计单个交易处理量以及总交易量信息业务目标/业务拓展计划：目前的生产业务量和用户数以及系统预期业务目标和本次测试预期业务指标业务信息调研文档资料调研功能规格说明书系统设计文档生产运营统计前期系统测试资料测试环境调研架构层次服务器名称服务器功能描述CPU数量内存大小（GB）主机类型操作系统Web层Web接入服务器24LinuxRHEL4U6应用层AP1XX系统性能测试48HPPA-RISCHP-UX11.11AP2XX系统性能测试48HPPA-RISCHP-UX11.11数据库层DB1在线数据库48IBMAIX5304DB2在线数据库48IBMAIX5304架构层次CPU内存磁盘网络操作系统应用服务器测试指标及测试数据交易处理能力TPS（笔/秒）：500平均响应时间：webservice交易2秒；报表5秒系统资源使用率：75%失败率（不包括返回错误的正常交易）：1%测试指标：测试数据：数据类型数据量表名称表关系幵发用户数指在同一时刻内，登录系统幵进行业务操作的用户数量。幵发用户数对于长连接系统来说最大幵发用户数即是系统的幵发接入能力。对于短连接系统而言最大幵发用户数幵丌等于系统的幵发接入能力，而是不系统架构、系统处理能力等各种情况相关。并发用户数第一年第二年第三年第四年第五年业务量业务量=第一年*（１+２０）*１００%业务量=第一年*（１+２０）*１００%业务量=第一年*（１+２０）*１００%业务量=第一年*（１+２０）*１００%计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力好的系统，扩展指标应是线性或接近线性的，且扩展能力应该在70%以上。增加性能增加资源系统可扩展性指标整体目录可用性统计分析排队论在分析过程中的应用性能问题实例理解性能测试性能测试需求的获取和分析性能测试执行、控制及分析可能的瓶颈点分析问题性能测试执行性能测试计划网络/OS/APServer隔离问题找出瓶颈点性能调整QA知识管理标准制定性能问题分析流程ClientEnvironment/Networking/WeborAPServer/EJB/DBServer/OS/JVM/LegacySystemNetworkWebServerAPServerDBServerJVM/OSLegacySystemClientEnvironment从系统架构分析瓶颈点故障征兆■持续运行缓慢。时常发现应用程序运行缓慢。通过改变环境因子（如负载量、数据库连接数等）也无法有效提升整体响应时间。■系统性能随时间的增加逐渐下降。在负载稳定的情况下，系统运行时间越长速度越慢。可能是由于超出某个阈值范围，系统运行频繁出错从而导致系统死锁或崩溃。■系统性能随负载的增加逐渐下降。随着用户数目的增多，应用程序的运行越发缓慢。若干个用户退出系统后，应用程序便能够恢复正常运行状态。■间发性的系统挂起或异常错误。有时候可能受负载或其它因素影响，当面不能完全显示，又或者是追踪到异常和堆栈的错误页，用户此时会看到系统挂起的情况。系统挂起的次数可能会稍有不同，然而即便是经过预烧（“burnin”）试验也无法完全消除。■可预见的死锁。系统挂起或系统出错发生的频率随着时间的推移明显增多，直到系统完全死锁。通常借助自动重启的故障管理模式解决上述问题。■系统突然出现混乱。系统正常运行，且在或多或少的一段时间内（譬如，可以是1小时也可以是3天）拥有一致优越的运行性能，却突然毫无征兆地出错甚至死锁。系统故障征兆“疾病”描述征兆原因或解决方法内存泄漏呈线性增长各单元（如每个事务或每个用户等）的内存泄漏，导致内存使用率随时间或负载的增加呈线性增长。系统性能随时间或负载的增加大幅下降，重启后系统可恢复正常系统性能随时间的增加逐渐下降,系统性能随负载的增加逐渐下降虽然有许多外在因素存在（如各单元数据的链表存储、尚未回收的缓冲中的回收或增长操作等），但最为常见的原因还是资源泄漏内存泄漏呈指数级增长内存泄漏呈双倍增长，导致系统内存消耗随时间呈指数曲线变化系统性能随时间的增加逐渐下降,系统性能随负载的增加逐渐下降虽然有许多外在因素存在（如各单元数据的链表存储、尚未回收的缓冲中的回收或增长操作等），但最为常见的原因还是资源泄漏导致无限循环的编码缺陷线程在while语句返回值为真的情况下发生阻塞，将最终演变成为CPU密集型和等待密集型或螺旋等待变量可预见的死锁需要进行侵入式循环切除资源泄漏JDBC语句、CICS事务网关连接等出现资源泄漏，引发Java桥接层和后台系统出现严重性能问题系统性能随时间的增加逐渐下降,可预见的死锁,系统突然出现混乱通常是由于遗漏了Finally模块，或者只是没有用close函数关闭代表外部资源的对象外部瓶颈后台或其它外部系统（如用户验证）运行缓慢，大大影响J2EE应用服务器及应用程序的运行速度系统持续缓慢运行,系统性能随负载的增加逐渐下降向专家（包括可靠的第三方或系统管理员等）咨询特定外部瓶颈问题的有效解决方法系统常见问题及解决方法“疾病”描述征兆原因或解决方法外部系统的过度使用J2EE应用程序发送的请求过大过多，滥用后台系统资源系统持续缓慢运行,系统性能随负载的增加逐渐下降消除冗余的工作请求，分批处理同类工作请求，把大请求细分为若干个小请求，调整工作请求或后台系统（例如为公共查询的关键字建立索引）等频繁调用CPU密集型组件的编码缺陷J2EE领域的通病是：些许编码缺陷或少量编码的交互失败，都会令CPU挂起，从而将数据流量速度降至蜗行系统持续缓慢运行,系统性能随负载的增加逐渐下降最好的解决方法是将数据存储在本地缓存中，或者为执行算法配备高速缓冲存储器桥接层本身存在的问题桥接层（如JDBC驱动、CORBA到遗留系统的连接等）存在执行缺陷。需要不断对数据和请求作编组和取消编组操作，导致该层的数据流量速度降至蜗行。这种故障现象在早期阶段与外部瓶颈极为相似系统持续缓慢运行,系统性能随负载的增加逐渐下降检查桥接层与外部系统的版本是否兼容。如果可能的话，对不同桥接供应商进行评估。通过重新规划设计系统架构，则可完全旁路桥接层内部资源瓶颈：资源的过度使用或分配不足内部资源（如线程、放入存储池的对象等）匮乏，却无法判断是正常情况下随负载增加而引起的资源过度使用，还是由于资源泄漏引起系统性能随负载的增加逐渐下降,间发性的系统挂起或异常错误若因资源分配不足引起，则可依照最大预期负载值上调存储池的最大容量；若因资源过度使用引起，请参看本表“外部系统的过度使用”一栏系统常见问题及解决方法“疾病”描述征兆原因或解决方法不断重试失败请求的频繁重试（某些极端情况下将无休止重试）可预见的死锁系统突然出现混乱后台系统可能已经完全宕机。监控系统可用性对这样的状况有所帮助，也可以只是将多次重复尝试的请求从成功的请求中筛选出来线程阻塞点线程退回到无法完成的同步点，造成通信阻塞系统性能随负载的增加逐渐下降,间发性的系统挂起或异常错误,可预见的死锁,系统突然出现混乱或许根本没有必要进行同步（只需对系统重新设计稍加改良），当然也可以定制一些外在的锁定策略（如读取器或写入器的读/写锁）线程的死锁或活锁通常只是“获取顺序”问题系统突然出现混乱解决方法选项包括主锁、即定的获取顺序以及银行家算法网络饱和等待时间长或基本无法将任何请求打包，导致系统异常停运、系统挂起或活锁等情况的出现系统持续缓慢运行,系统性能随负载的增加逐渐下降,间发性的系统挂起或异常错误如此棘手的问题正在侵蚀着网络系统，如果不及时升级系统的基础架构，提升网络及路由器的运行速度，将无法扼制日后类似问题的出现系统常见问题及解决方法网络两点之间数据分析引导使用者提供完整的信息◦When(何时发生？)◦What(那个操作？)◦Who(谁操作的？)◦Where(在何处操作？)◦How(操作程序？)分析性能问题需要的信息首先获得数据库系统中每一条SQL语句在数据库中执行的平均时间然后将效率低下并且频繁调用的SQL语句的执行时间划分为四部分：解析时间（ParseTime）、执行时间（ExecuteTime）、读取时间（FetchTime）和其他时间（OtherTime），其中其他时间包括数据库中消耗的一些时间，例如绑定时间（bindtime）优化SQL语句SQL性能分析数据库锁管理数据库lock管理数据库latch管理sql语句的优化sql语句的定位sql语句的执行计划全表扫描语句的定位sql语句的优化建议SQL性能分析ResponseTime=ProcessTime+QueueTime◦Processtime:averageresponsetimeofsinglethread◦Queuetime:averageresponsetimeofmultithreadsQueueTime=QueueLength*ProcessTime表示响应时间突然增加意味着一种或者多种系统资源的利用达到了极限调优的方法◦每次改变一个系统参数或者一个应用逻辑◦使用固定的负载◦测试另一个设置之前收集本次性能测试的数据。◦重复测试过程，直到应用程序的性能达到了期望的状态。例如：◦很多Web服务器可以设置固定数量的threads来处理用户同时发出的请求。◦当这些并发的请求数量超过当前有效的threads数量时，任何新到的请求将会被放入