性能测试指标
软件测试中的性能指标与评估方法
软件测试中的性能指标与评估方法软件测试是确保软件产品质量的重要环节，而其中之一的性能测试更是至关重要。
性能指标与评估方法的选择和运用，可以帮助开发人员和测试人员更好地评估软件系统的性能表现，提升系统的可靠性和稳定性。
本文将介绍软件测试中常用的性能指标和评估方法。
一、性能指标1. 响应时间：即软件系统对请求的响应速度。
客户端发送请求到服务器响应完成的时间，是评估系统性能的关键指标之一。
2. 吞吐量：系统在单位时间内能够处理的请求数量。
通过统计单位时间内的请求完成数量，来评估系统的处理能力。
3. 并发用户数：指同时访问系统的用户数量。
并发用户数的增加会对系统性能产生一定的压力，通过对并发用户数的测试和评估，可以确定系统的容量上限。
4. 容量：指系统支持的最大用户数量或最大数据处理量。
容量测试可以帮助开发人员了解系统在扩展性和可用性方面的表现。
5. 稳定性：系统在高负载和复杂场景下的表现。
通过稳定性测试，可以评估系统在长时间运行或异常情况下的性能表现。
二、性能评估方法1. 负载测试：通过模拟用户请求，对系统进行压力测试。
可以确定系统在承载高负载情况下的性能表现，并评估系统的容量和吞吐量。
2. 性能剖析：通过工具对系统进行监控和分析，找出性能瓶颈和优化点。
如使用性能监控工具分析数据库查询性能，提升系统的响应速度。
3. 并发测试：模拟多个用户同时访问系统，评估系统在并发用户数增加时的性能表现。
通过并发测试，可以确定系统在高并发场景下是否稳定。
4. 容量规划：通过对系统的容量需求和性能指标进行预测和规划，确保系统在用户量增加时仍然能够保持良好的性能。
5. 压力测试：通过增加负载和并发用户数，对系统进行高压力测试。
可以评估系统在极限情况下的性能表现，发现系统的弱点并做好优化工作。
总结软件测试中的性能指标与评估方法，对于确保软件系统的可靠性和稳定性至关重要。
合理选择和运用性能指标和评估方法，能够帮助开发人员和测试人员更好地评估系统的性能表现，并在测试过程中及时发现和解决性能问题。
性能测试关注指标
性能测试关注指标⼀、接⼝请求响应指标重点关注以下⼏个指标：需满⾜的并发数TPS（每秒处理事务的能⼒）响应时间（平均响应时间、90%响应时间）错误率性能测试指标通过标准需满⾜的并发数（举例：每天8W⽤户访问，平均在线时长10分钟，1天⽤户24⼩时内使⽤系统）C = 80000 * 0.166/24=553注：0.166为10/60得出C = nL/TC^= C + 3*根号C其中C为平均并发⽤户数，n为login session的数量，L是login session的平均长度，T是值考察的时间长度C^为并发⽤户数峰值需满⾜的TPSTPS = （80000*80%）/(20%*8*60*60)=11/sec 据⼆⼋原则：20%常⽤时间，满⾜80%业务量TPS = n*80%/(20%*活跃时间*60*60)注：活跃时间⼀般为8⼩时响应时间根据在并发情况下的响应时间2/5/10原则，最长不能超过10s 错误率具体系统具体要求，⼀般⼩于万分之⼀缓存命中率具体系统具体要求，⼀般⼤于85%通过CPU占⽤率70% 好，85% 坏，90%+ 很差内存使⽤率⼀般⼩于80%通过⼆、服务器性能指标重点关注以下⼏个指标：线程对cpu占⽤（关注）对内存占⽤（关注）磁盘I/O⽹络情况性能项资源评价CPU占⽤率70%好85%坏90%+很差磁盘I/0<30%好<40%坏<50%+很差⽹络<30%带宽好运⾏队列<2*CPU数量好内存没有页交换好每个CPU每秒10个页交换坏更多的页交换很差更多的页交换很差使⽤命令查看CPU、内存变化情况：top -b -d 1 -p 27854 > 0904logp是进程号，d是1秒收集⼀次，要⽤root⽤户（sudo su -）查看进程号 ps ef |grep acs-job 若重启服务器后，pid会发⽣变化，必须重新获取三、SQLServer数据库查询慢语句(需数据库管理员权限) --总耗CPU最多的前20个SQL:SELECT TOP 20total_worker_time/1000 AS [总消耗CPU 时间(ms)],execution_count [运⾏次数],qs.total_worker_time/qs.execution_count/1000 AS [平均消耗CPU 时间(ms)],last_execution_time AS [最后⼀次执⾏时间],max_worker_time /1000 AS [最⼤执⾏时间(ms)], SUBSTRING(qt.text,qs.statement_start_offset/2+1,(CASE WHEN qs.statement_end_offset = -1THEN DATALENGTH(qt.text)ELSE qs.statement_end_offset END -qs.statement_start_offset)/2 + 1)AS [使⽤CPU的语法], qt.text [完整语法],qt.dbid, dbname=db_name(qt.dbid),qt.objectid,object_name(qt.objectid,qt.dbid) ObjectNameFROM sys.dm_exec_query_stats qs WITH(nolock)CROSS apply sys.dm_exec_sql_text(qs.sql_handle) AS qtWHERE execution_count>1ORDER BY total_worker_time DESC--平均耗CPU最多的前20个SQL:SELECT TOP 20total_worker_time/1000 AS [总消耗CPU 时间(ms)],execution_count [运⾏次数],qs.total_worker_time/qs.execution_count/1000 AS [平均消耗CPU 时间(ms)],last_execution_time AS [最后⼀次执⾏时间],min_worker_time /1000 AS [最⼩执⾏时间(ms)], max_worker_time /1000 AS [最⼤执⾏时间(ms)],SUBSTRING(qt.text,qs.statement_start_offset/2+1,(CASE WHEN qs.statement_end_offset = -1THEN DATALENGTH(qt.text)ELSE qs.statement_end_offset END -qs.statement_start_offset)/2 + 1)AS [使⽤CPU的语法], qt.text [完整语法],qt.dbid, dbname=db_name(qt.dbid),qt.objectid,object_name(qt.objectid,qt.dbid) ObjectNameFROM sys.dm_exec_query_stats qs WITH(nolock)CROSS apply sys.dm_exec_sql_text(qs.sql_handle) AS qtWHERE execution_count>1ORDER BY (qs.total_worker_time/qs.execution_count/1000) DESC四、mysql慢查询相关命令-- 检查慢查询命令是否开启show variables like '%query';-- 查看慢查询命令select * from mysql.slow_log;。
性能测试通常需要监控的指标
性能测试通常需要监控的指标在进行性能测试时，需要监控以下指标以评估系统的性能和效率：1.响应时间：响应时间是衡量系统响应请求的速度。
它是从发送请求到收到相应的时间间隔。
较短的响应时间表示系统运行速度快，用户获得结果的等待时间短。
2.吞吐量：吞吐量是单位时间内系统处理的请求数量。
它表示系统的处理能力，较高的吞吐量意味着系统能够同时处理更多的请求。
3.并发用户数：并发用户数指同时访问系统的用户数量。
它反映了系统能够同时支持的用户数量，较高的并发用户数表示系统能够处理更多的并发请求。
4.CPU使用率：CPU使用率表示当前系统的CPU利用率。
它反映了系统的负载情况，较高的CPU使用率可能导致系统性能下降。
5.内存使用率：内存使用率表示当前系统的内存利用率。
它反映了系统内存的负载情况，较高的内存使用率可能导致系统出现内存不足的情况。
6.网络延迟：网络延迟是从发送请求到接收到响应的时间间隔。
它反映了网络传输的速度和稳定性，较短的网络延迟表示网络传输速度快。
7.数据库响应时间：对于涉及数据库的系统，需要监控数据库的响应时间。
较短的数据库响应时间表示数据库访问效率高。
8.磁盘I/O：磁盘I/O是指磁盘的读写操作。
需要监控磁盘的读写速度和响应时间，较高的磁盘I/O可能影响系统的性能和效率。
9.错误率：错误率表示系统处理请求时出现错误的比率。
较低的错误率表示系统稳定性高，较高的错误率可能表示系统存在问题。
10.带宽利用率：带宽利用率表示当前网络带宽的利用率。
较高的带宽利用率可能导致网络拥堵和传输速度下降。
11.日志记录：性能测试还需要监控系统的日志记录，以便分析和诊断问题。
需要记录系统的运行日志、错误日志和性能日志等。
通过监控这些指标，可以评估系统的性能和效率，并及时发现和解决潜在的性能问题。
性能测试指标
性能测试指标XXX系统性能指标包括以下内容：1、登陆时间≤5秒；2、页面间跳转时间≤3秒；3、精确查询（包括请求服务）响应时间≤1秒；4、模糊查询响应时间≤5秒；5、全文检索、综合查询响应时间≤3秒；6、简单事务处理（包含各类信息录入、修改、删除）≤4秒；7、各类固定统计报表形成时间≤60秒；8、各种比对、分析、布控等复杂事务处理≤120秒；9、支持静态用户（注册用户）在50000以上；10、支持动态用户（在线用户）在1500以上；11、支持并发数300以上；12、系统有效工作时间要求≥99.5%；13、系统故障平均间隔时间：≥30天；14、系统一年的故障停机时间不超过15分钟（停电等不可预测因素除外）。
15、避免出现以下情况：无故退出系统；出现系统不可控的故障提示；因系统故障导致操作系统或机器无法正常工作。
高性能服务接口必须符合平台技术规范，具备一定的性能扩展能力，具备一定的非法应用请求检测能力。
具体性能指标包括：并发响应能力高于500个；数据查询服务中精确查询响应时间小于0.3秒，其他查询响应时间小于0.5秒；小批量数据比对服务响应时间小于0.5秒；服务执行成功率大于99%，服务正常运行率大于99%。
性能测试流程：1.确定系统的并发用户数；2.设计性能测试用例，原则以在高峰时期并发情况较多的操作作为用例基础。
3。
硬件环境准备，这和性能测试的结果有直接关系。
做性能测试的目的之一就是要知道我们的软件系统在特定的硬件环境下最多能承受多少并发用户，当然这要在多次调整各方面性能参数才能定下来。
4。
专业的测试工具嘛做大项目是需要的。
商业的有Loadrunner,QALoad（我常用的压力测试工具），免费的就更多了。
他们一般都可录制测试脚本，但这不算完。
我们需要监控服务器端的性能参数变化，比如Oracle数据库的缓存命中率.....Unix服务器。
windows服务器，应用服务器.....还要将录制脚本填写表单的数据做参数化，即商业测试工具所谓的数据池功能－－－目的是不要使数据重复(数据表中的主键等限制)，而且可以真正的模拟不同用户作不同操作的情况。
性能测试参数指标值方案
性能测试参数指标值方案性能测试是一种测试方法，用于评估系统在不同负载下的性能表现。
在进行性能测试时，需要选择合适的性能测试参数指标值来衡量系统的性能。
本文将介绍一些常见的性能测试参数指标值，并提供一种1200字以上的方案。
一、响应时间（Response Time）响应时间是指用户发起请求后，系统响应请求所需的时间。
响应时间是评估系统性能的重要指标，常用单位为毫秒（ms）。
可以设置不同的负载场景，通过监测系统在不同负载下的响应时间，来评估系统的性能。
二、并发用户数（Concurrency）并发用户数是指系统同时能够处理请求的用户数量。
通过逐渐增加并发用户数，观察系统的性能表现。
常用的并发用户数指标值为100、500、1000等。
三、吞吐量（Throughput）吞吐量是指在单位时间内系统处理的请求数量。
吞吐量一般以每秒请求数（TPS）或每分钟或每小时请求数来衡量。
通过增加负载，观察系统的吞吐量，来评估系统的性能。
通常，可将吞吐量的指标值设置为500、1000、2000等。
四、错误率（Error Rate）错误率是指系统在处理请求时产生错误的比例，常用百分比表示。
通过监测系统的错误率，可以评估系统在不同负载下的稳定性和可靠性。
通常，可将错误率设置为1%、2%或更低值。
五、CPU使用率（CPU Usage）CPU使用率是指系统在处理请求时使用的CPU资源占总CPU资源的比例。
通过监测系统的CPU使用率，可以评估系统的处理能力。
通常，可以将CPU使用率的指标值设置为50%、70%或更高值。
六、内存占用（Memory Consumption）内存占用是指系统在处理请求时使用的内存资源量。
通过监测系统的内存占用情况，可以评估系统的性能和稳定性。
通常，可以将内存占用的指标值设置为500MB、1GB或更高值。
七、网络延迟（Network Latency）网络延迟是指从用户发送请求到服务器响应请求所需的时间。
通过监测系统的网络延迟，可以评估系统的响应速度和网络传输性能。
性能测试常用指标：响应时间,吞吐量,TPS,QPS,并发数,点击数,资源利用率,错误率
性能测试常⽤指标：响应时间,吞吐量,TPS,QPS,并发数,点击数,资源利⽤率,错误率对于性能测试,以上性能指标必须要有清楚的理解,⾃⼰总结如下:1. 响应时间(RT) 是指系统对请求作出响应的时间。
这个指标与⼈对软件性能的主观感受是⼀致的，因为它完整地记录了整个计算机系统处理请求的时间。
由于⼀个系统通常会提供许多功能，⽽不同功能的处理逻辑也千差万别，因⽽不同功能的响应时间也不尽相同，甚⾄同⼀功能在不同输⼊数据的情况下响应时间也不相同。
所以，在讨论⼀个系统的响应时间时，⼈们通常是指该系统所有功能的平均时间或者所有功能的最⼤响应时间。
当然，往往也需要对每个或每组功能讨论其平均响应时间和最⼤响应时间。
对于单机的没有并发操作的应⽤系统⽽⾔，⼈们普遍认为响应时间是⼀个合理且准确的性能指标。
需要指出的是，响应时间的绝对值并不能直接反映软件的性能的⾼低，软件性能的⾼低实际上取决于⽤户对该响应时间的接受程度。
对于⼀个游戏软件来说，响应时间⼩于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。
⽽对于编译系统来说，完整编译⼀个较⼤规模软件的源代码可能需要⼏⼗分钟甚⾄更长时间，但这些响应时间对于⽤户来说都是可以接受的。
注意: 在性能测试中, 响应时间要做更细致划分2. 吞吐量(Throughput)吞吐量是指系统在单位时间内处理完成的客户端请求的数量, 直接体现软件系统的性能承载能⼒。
这是⽬前最常⽤的性能测试指标。
对于服务器来讲,吞吐量越⾼越好.吞吐量是⼀个很宽泛的概念, 通常情况下，⽤“请求数/秒”或者“页⾯数/秒”来衡量。
体现:1. 业务⾓度: 业务数/⼩时或访问⼈数/天等2. ⽹络流量: 字节数/⼩时或字节数/天等3. 服务器性能处理能⼒(重点): TPS(每秒事务数) 和 QPS(每秒查询数):对于⽆并发的应⽤系统⽽⾔，吞吐量与响应时间成严格的反⽐关系，实际上此时吞吐量就是响应时间的倒数。
性能测试报告里包含哪些关键的性能指标
性能测试报告里包含哪些关键的性能指标我们做性能测试的目标是，在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而分析出系统瓶颈，提高系统的稳定性。
而在一份性能测试报告里，会看到以下的这些关键的数据指标：最大并发用户数，HPS（点击率）、事务响应时间、每秒事务数、每秒点击量、吞吐量、CPU使用率、物理内存使用、网络流量使用等。
但性能测试的指标，前后端的性能测试关注点是不一样的。
前端需主要关注的点是：响应时间：用户从客户端发出请求，并得到响应，以及展示出来的整个过程的时间。
加载速度：通俗的理解为页面内容显示的快慢。
流量：所消耗的网络流量。
后端需主要关注的是：响应时间：接口从请求到响应、返回的时间。
并发用户数：同一时间点请求服务器的用户数，支持的最大并发数。
内存占用：也就是内存开销。
吞吐量（TPS）：Transaction Per Second, 每秒事务数。
在没有遇到性能瓶颈时：TPS=并发用户数某事务数/响应时间。
错误率：失败的事务数/事务总数。
资源使用率：CPU占用率、内存使用率、磁盘I/O、网络I/O。
系统性能指标、资源性能指标、稳定性指标一、系统性能指标常见的可从如下几类进行参考：响应时间系统处理能力吞吐量并发用户数错误率1、响应时间简称RT，指的是客户发出请求到得到系统响应的整个过程的时间。
也就是用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。
直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。
2、系统处理能力指系统在利用系统硬件平台和软件平台进行信息处理的能力。
系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。
前者称为业务交易过程，后者称为事务（事务是用户其中一步或几步操作的集合）。
两种交易指标都可以评价应用系统的处理能力。
性能测试指标TPS（TransactionperSecond）总结
性能测试指标TPS（TransactionperSecond）总结性能测试指标TPS（Transaction per Second）总结TPS（Transaction per Second）定义： tps是Transaction per Second的缩写，也就是事物数/秒。
它是软件测试结果的测量单位，⼀个事物是指⼀个客户机向服务器发送请求饭后服务器做出反应的过程。
客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使⽤时间和完成的事物数，最终利⽤这些信息来估计得分。
TPS（Transaction per Second）作⽤： 反映了系统在同⼀时间内处理业务的最⼤能⼒，这个数据越⾼，说明处理能⼒越强，描述（看到系统的TPS随着时间的变化逐渐变⼤，⽽在不到多少分钟的时候系统 每秒可以处理多少个事物。
这⾥的最⾼值并不⼀定代表系统的最⼤处理能⼒，TPS会受到负载的影响，也会随着负载增加⽽逐渐增加，当系统进⼊繁忙期后，TPS会有所下降。
） ⽽在⼏分钟以后开始出现少量的失败事物）TPS（Transaction per Second）局限性： 1、tps是从客户端⾓度审视服务器处理能⼒，并不是说TPS可以达到什么程度就能⽀持多少并发（例如：⼀个业务100个交易，另⼀个业务10个交易）。
2、TPS = 脚本运⾏期间所有事物总数 / 脚本运⾏时长，如果使⽤集合点策略，在脚本执⾏前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不⼀致。
3、限制TPS的原因：服务器本⾝性能、代码结构、客户端施加的压⼒以及⽹卡等。
TPS（Transaction per Second）与响应时间的关系： 1、TPS和响应时间在理想状态下的额定值。
如果20个⼊⼝，并发数只有10的时候，TPS就是10，⽽响应时间始终都是1，说明并发不够，需要增加并发数达到TPS的峰值。
2、如果增加到100并发，则造成了线程等待，引起平均响应时间从 1 秒变成 3 秒，TPS也从20下降到9；TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Weｂ性能测试的部分概况一般来说,一个Ｗeb请求的处理包括以下步骤:(1)客户发送请求(2)weｂservｅr 接受到请求,进行处理;(3)weｂ servｅｒ向ＤB获取数据;(４)web serｖｅr生成用户的obｊeｃt(页面),返回给用户。
给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中)。
1.事务(Tranｓacｔion)在ｗeb性能测试中,一个事务表示一个“从用户发送请求->web sｅrveｒ接受到请求,进行处理-＞ｗeｂ serveｒ向DＢ获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都就是针对事务而言的。
2、请求响应时间请求响应时间指的就是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应通常会称为“TTLB”,即＂tｉme ｔｏ lａst ｂｙｔe",意思就是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。
一个公式可以表示:响应时间＝网络响应时间+应用程序响应时间。
标准可参考国外的3/５/1０原则:(1)在3秒钟之内,页面给予用户响应并有所显示,可认为就是“很不错的”;(2)在３~５秒钟内,页面给予用户响应并有所显示,可认为就是“好的”;(３)在5～10秒钟内,页面给予用户响应并有所显示,可认为就是“勉强接受的”;(４)超过１0秒就让人有点不耐烦了,用户很可能不会继续等待下去;3、事务响应时间事务可能由一系列请求组成,事务的响应时间主要就是针对用户而言,属于宏观上的概念,就是为了向用户说明业务响应时间而提出的、例如:跨行取款事务的响应时间就就是由一系列的请求组成的、事务响应时间就是直接衡量系统性能的参数、４.并发用户数并发一般分为2种情况。
一种就是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。
比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。
另外一种并发就是广义范围的并发。
这种并发与前一种并发的区别就是,尽管多个用户对系统发出了请求或者进行了操作,但就是这些请求或者操作可以就是相同的,也可以就是不同的。
对整个系统而言,仍然就是有很多用户同时对系统进行操作,因此也属于并发的范畴。
可以瞧出,后一种并发就是包含前一种并发的。
而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。
对于ＷEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法就是先进行严格意义上的并发测试。
严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不就是很大,但就是一旦发生性能问题,后果很可能就是致命的。
严格意义上的并发测试往往与功能测试关联起来,因为并发功能遇到异常通常都就是程序问题,这种测试也就是健壮性与稳定性测试的一部分。
用户并发数量:关于用户并发的数量,有２种常见的错误观点。
一种错误观点就是把并发用户数量理解为使用系统的全部用户的数量,理由就是这些用户可能同时使用系统;还有一种比较接近正确的观点就是把在线用户数量理解为并发用户数量。
实际上在线用户也不一定会与其她用户发生并发,例如正在浏览网页的用户,对服务器没有任何影响,但就是,在线用户数量就是计算并发用户数量的主要依据之一。
5.吞吐量指的就是在一次性能测试过程中网络上传输的数据量的总与、吞吐量/传输时间,就就是吞吐率、6、TPS(traｎｓａcｔｉon ｐｅr sｅcond)每秒钟系统能够处理的交易或者事务的数量、它就是衡量系统处理能力的重要指标.7、点击率每秒钟用户向WEB服务器提交的ＨTTP请求数、这个指标就是WEB应用特有的一个指标:WEB应用就是＂请求－响应"模式,用户发出一次申请,服务器就要处理一次,所以点击就是ＷEB应用能够处理的交易的最小单位、如果把每次点击定义为一个交易,点击率与TＰＳ就就是一个概念、容易瞧出,点击率越大,对服务器的压力越大、点击率只就是一个性能参考指标,重要的就是分析点击时产生的影响。
需要注意的就是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HＴTP请求、８、资源利用率指的就是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率就是分析系统性能指标进而改善性能的主要依据,因此就是ＷEＢ性能测试工作的重点、资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,就是测试与分析瓶颈的主要参考、在WEB性能测试中,更根据需要采集相应的参数进行分析。
通用指标(指Web应用服务器、数据库服务器必需测试项)指标说明ProceｓsorTime 服务器CPU占用率,一般平均达到7０%时,服务就接近饱与Memory Available Mｂytｅﻩ可用内存数,如果测试时发现内存有变化情况也要注意,如果就是内存泄露则比较严重Ｐhyｓicsdisk Timｅ物理磁盘读写时间情况Ｗeb服务器指标指标说明Reqｕests Peｒ Seｃｏｎd(Avg Rｐｓ) 平均每秒钟响应次数＝总请求时间 / 秒数Avｇ timｅ tｏ last bytｅｐeｒ terstiｏn(msteｓ) 平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆Sｕｃcessful Rounｄs 成功的请求Fａileｄ Reｑuests 失败的请求Ｓｕccesｓｆul Hiｔｓ成功的点击次数Fａiled Hｉｔsﻩ失败的点击次数Hiｔs Ｐer Secondﻩ每秒点击次数Succｅssfuｌ HitｓＰｅｒ Sｅcond 每秒成功的点击次数Failed Hits Ｐｅr Seｃoｎｄﻩ每秒失败的点击次数Aｔｔeｍpted Ｃonnections 尝试链接数数据库服务器性能指标指标ﻩ说明User0Cｏnnectiｏns 用户连接数,也就就是数据库的连接数量Nｕmbeｒof deaｄloｃks 数据库死锁Bｕtter Cache hitﻩ数据库Ｃacｈe的命中情况系统的瓶颈定义性能项命令指标CPＵ限制ﻩｖmsｔａｔ当%usｅr＋%ｓｙs超过80％时磁盘Ｉ/Ｏ限制Vmstat 当%iowait超过４0％(ＡＩX4、３.3或更高版本)时应用磁盘限制Iｏstaｔﻩ当%tｍ＿acｔ超过70%时虚存空间少Lsｐｓ,-aﻩ当分页空间的活动率超过70%时换页限制Iostat,statﻩ虚存逻辑卷%tm_ａct超过I/Ｏ(ioｓｔat)的30％,激活的虚存率超过CＰＵ数量(vmsｔat)的１0倍时系统失效ﻩVmstat, saｒﻩ页交换增大、CPＵ等待并运行队列稳定系统的资源状态性能项ﻩ资源评价CＰU占用率ﻩ７０%ﻩ好８5% 坏90%+ 很差磁盘I/０<30%ﻩ好<40%ﻩ坏＜5０%+ 很差30%带宽ﻩ好网络ﻩ<运行队列ﻩ<２＊ＣＰU数量好内存没有页交换ﻩ好每个CPＵ每秒10个页交换ﻩ坏更多的页交换ﻩ很差通俗理解:日访问量常用页面最大并发数同时在线人数访问相应时间案例:最近公司一个项目,就是个门户网站,需要做性能测试,根据项目特点定出了主要测试项与测试方案:一种就是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)一种就是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)一种则需要测试服务器能否接受10万用户同时在线操作,如果就是用IIS做应用服务器的话,单台可承受的最大并发数不可能达到10万级,那就必须要使用集群,通过多台机器做负载均衡来实现;如果就是用weｂspｈｅre之类的应用服务器的话,单台可承受的最大并发数可以达到1０万级,但为性能考虑还就是必须要使用集群,通过多台机器做负载均衡来实现;通常有1个简单的计算方式,1个连接产生1个ｓession,每个ｓｅｓsion在服务器上有个内存空间大小的设置,在ＮT上就是３M,那么10万并发就需要３00G内存,当然实际使用中考虑其她程序也占用内存,所以准备的内存数量要求比这个还要多一些。
还有１０万个用户同时在线,跟１0万个并发数就是完全不同的2个概念。
这个楼上已经说了。
但如何做这个转换将1０万个同时在线用户转换成多少个并发数呢?这就必须要有大量的历史日志信息来支撑了。
系统日志需要有同时在线用户数量的日志信息,还需要有用户操作次数的日志信息,这2个数据的比例就就是您同时在线用户转换到并发数的比例。
另外根据经验统计,对于１个ＪAVＡ开发的WＥB系统(别的我没统计过,给不出数据),一般１台双CPU、2G内存的服务器上可支持的最大并发数不超过5００个(这个状态下大部分操作都就是超时报错而且服务器很容易宕机,其实没什么实际意义),可正常使用(单步非大数据量操作等待时间不超过２0秒)的最大并发数不超过３00个。
假设您的10万同时在线用户转换的并发数就是900０个,那么您最少需要这样的机器18台,建议不少于３０台。
当然,您要就是买个大型服务器,里面装有20０个CPU、2５６G的内存,千兆光纤带宽,就算就是１0万个并发用户,那速度,也绝对就是嗖嗖的。
另外暴寒1下,光设置全部进入运行状态就需要接近6个小时。
具体的可以拿１个系统来压一下瞧瞧,可能会出现以下情况:1、服务器宕机;2、客户端宕机;３、从某个时间开始服务器拒绝请求,客户端上显示的全就是错误;4、勉强测试完成,但网络堵塞或测试结果显示时间非常长。
假设客户端与服务器之间百兆带宽,百兆/1０0０0=１0K,那每个用户只能得到1０Ｋ,这个速度接近１个６4K的MＯＤEＭ上网的速度;另外以上分析全都没考虑系统的后台,比如数据库、中间件等。
１、服务器方面:上面说的那样的PCＳERVEＲ需要50台;2、网络方面:按每个用户５0K,那至少５根百兆带宽独享,估计仅仅网络延迟就大概就是秒一级的;３、如果有数据库,至少就是ORＡCLE,最好就是SＹＳBASE,ＳQＬSEＲVER就是肯定顶不住的。
数据库服务器至少需要10台４ＣＰU、１６Ｇ内存的机器;4、如果有ＣＯRＢA,那至少再准备10台4CPＵ、16G内存的机器;再加上负载均衡、防火墙、路由器与各种软件等,总之没个100０万的资金投入,肯定搞不定。
这样的门户系统,由于有用户权限,所以并不象ｊａｃｋie所说大多就是静态页面。
但只要就是多服务器的集群,那么我们就可以通过1台机器的测试结果来计算多台机器集群后的负载能力的,最多额外考虑一下负载均衡与路由上的压力,比如带宽、速度、延迟等。