性能测试

一、性能测试概念 性能：事务、物品的某些特性的评价值 性能测试：通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试 二、性能测试指标 性能指标分为两个方面： 系统指标（与用户场景和需求相关指标） 资源指标（与硬件资源消耗相关指标） 1.响应时间 从发起请求到收到请求响应的时间 响应时间=网络响应时间+应用程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3) 2.并发数 单位时间内发起请求的用户数 并发用户数C，计算公式C=nL/T n：每天访问系统的用户数 L：在线用户从登陆到退出的时间 T：用户每天使用系统大概多长时间 峰值C1,即最大并发数，计算公式C1=C+³√C 最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待 最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候 3.吞吐量、吞吐率 衡量网络性能的重要指标 吞吐量：网络传输的数据量（处理客户的请求数） 吞吐率：单位时间（可以是秒/分/时/天）内网络成功传输的数据量，如请求数/秒、页面数/秒 4.事务、TPS 事务：一个动作或是一系列动作的集合，比如用户从登录到退出的一个场景就为一个事务 TPS：Transaction per second——最主要的性能指标，衡量服务器处理事务数的能力

顶尖高手帮你整理的性能测试方法大全 在这半年以来，我陆续参加或者独立承担的项目组版本的部分性能测试，慢慢的有了一些认识，暂时做一个积累，和大家做一个交流。 性能测试的需求背景一般来自于以下三种情况： 第一种是现网出现性能问题，项目组专门进行了性能改造。比如修改的某个接口，由原来的同步调用修改成了异步，又或者是更换了新的api，由tcp协议修改为udp协议，为了保证新替换的api的可靠性，都需要进行性能测试 第二种是一个新做的系统，运营人员需要全面的把脉，了解该系统的处理能力。 第三种是随着请求量的快速增长，而该系统却从未做过性能测试，项目组担心系统在可预见的短期会扛不住，所以要求测试人员对该进行全面的性能测试，给出一份参考数据 根据背景的不同我们往往有不同的准备方式，但是大致可以从以下几个方面入手准备。 1、全面了解该系统概况 （1）系统所期望的性能指标： 对于第一二两种情况，都会有很明确的现网性能指标，比如以前测试的acs，是一个新作的系统，需求说明书中就明确标注需要达到1wtps.而对于第三种情况，往往我们需要尽量的模拟现网，得出数据供运营做参考。 例如最近测试的查询限制引擎，测试这边给出了单台svr的处理能力以及是否支持平行扩展等运维最关心的数据即可。 （2）组网以及网间各个系统之间的通信形式： 有时我们性能改造只是组网中一个小小的系统

Redis 性能测试 Redis 性能测试是通过同时执行多个命令实现的。 语法 redis 性能测试的基本命令如下： redis-benchmark [option] [option value] 注意 ：该命令是在 redis 的目录下执行的，而不是 redis 客户端的内部指令。 实例 以下实例同时执行 10000 个请求来检测性能： $ redis-benchmark -n 10000 -q PING_INLINE: 141043.72 requests per second PING_BULK: 142857.14 requests per second SET: 141442.72 requests per second GET: 145348.83 requests per second INCR: 137362.64 requests per second LPUSH: 145348.83 requests per second LPOP: 146198.83 requests per second SADD: 146198.83 requests per second SPOP: 149253.73 requests per second LPUSH (needed to benchmark LRANGE): 148588.42 requests per

在进行性能测试之前，需要跟开发问清楚性能测试的目的，是为了找到系统能支撑的最大负载还是为了检查在一定负载下系统的运行情况。如果是后者的话，还需要问一下服务器端设置的最大并发线程数，这样测试时才能设置出合适的负载量。我之前做过的几次http请求的压测，都是为了找系统能支持的最大负载。本次压测，我先在本地测试，给了50个线程并循环100次，结果在测试运行一段时间后就会出现需要等待很长时间的情况，一开始以为是本地网络状况不佳，将脚本放在服务器上跑依然会出现这个情况，后来跟开发沟通知道服务端设置了最大并发量的限制，并且只需要测试一下特定线程下系统的性能情况即可。有了这次经验之后，在之后的性能测试前就知道要尽量问清楚测试需求了。 还有一点需要注意的是缓存对于性能的影响，有无缓存对性能的影响通常是很大的，需要跟开发确认好重点关注的是有缓存还时没有缓存的情况。本次压测，有一个测试类是查询文章subject（话题）属性的，话题属性是实时计算出来的，如果传入的docid是第一次调用该方法，返回话题属性耗时会比较长，之后再对同一个docid查询话题属性时是直接从缓存中取数据返回，耗时大大减少。对获取话题属性的方法进行性能测试，在40个线程、重复100次的压力下，没有缓存和有缓存时的TPS分别为70/s和2200/s，可见两种情况下的差距之大。 一般性能测试的时候还需要关注其他的一些信息

一个web请求的一般步骤 Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤： 客户发送请求 web server接受到请求，进行处理； web server向DB/cache获取数据； webserver生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中） 。 服务器计算 服务器数量 = ceil( 每天总PV / 单台服务器每天总PV ) 原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间 公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 问：每天300w PV 的在单台机器上，这台机器需要多少QPS？ 答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS) 问：如果一台机器的QPS是58，需要几台机器来支持？ 答：139 / 58 = 3问：如果一台机器的QPS是58，需要几台机器来支持？ 答：139 / 58 = 3 问：如果一台机器的QPS是58，需要几台机器来支持？ 答：139 / 58 = 3 问：如果一台机器的QPS是58，需要几台机器来支持？ 答：139 / 58 = 3

netperf 网络性能测试 Netperf 是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。 Netperf 根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。 工作原理 Netperf 工具以client/server方式工作。server端是netserver,用来侦听来自client端的连接,client端是 netperf ,用来向server发起网络测试.在client与server之间,首先建立一个控制连接,传递有关测试配置的信息,以及测试的结果:在控制连接建立并传递了测试配置信息以后，client与server之间会再建立一个测试连接,进行来回传递特殊的流量模式,以测试网络的性能 软件安装 下载安装 Netperf 工具 下载链接：ftp://ftp.netperf.org/netperf/ [root@xiesshavip001 ~]# wget ftp://ftp.netperf.org/netperf/netperf-2.7.0.tar.gz 安装依赖包gcc cc [root@xiesshavip001 ~]# yum install gcc cc -y 解压安装 [root@xiesshavip001 ~]# tar -zxvf

聊聊性能测试开始前的准备工作 转载： https://www.cnblogs.com/imyalost/p/9557741.html 之前的博客有介绍过 完整的性能测试的流程 和 性能测试需求分析 相关的内容，然而在实际的性能测试工作中，测试开始前也有很多的工作要做。 这篇博客，就聊聊性能测试的第一步工作：获取测试需求，到底需要哪些东西。。。 性能测试流程导图 一、相关设计文档 1、系统架构图 ：了解被测系统的技术架构，包括从客户端到DB的周转流程、应用服务器、中间件等； 2、网络拓扑图 ：和系统架构图类似，这个更多的是体现在不同层级之间的网络拓扑关系，也可以和系统架构图结合在一起，根据项目具体情况而定； 3、需求说明文档 ：了解被测系统的业务流程，不同模块间的关系，便于后面的业务场景建模； 4、接口设计文档 ：大多性能测试都是通过调用模块间的API来进行模拟并发，了解业务模型对应的API，包括协议类型、方法、传参类型、入参、出参等信息是很必要的； 5、数据库表设计文档 ：测试过程中产生的数据会写入哪个库哪个表，不同的API参数会对哪张表甚至哪个字段产生什么影响，熟悉“数据流”是很必要的一件事情； 二、确认性能指标or目的 1、测试目的 测试目的 说明 并发测试 测试系统在一定条件下可承受的最大并发数 容量测试 测试系统在一定配置下的最大服务能力 配置测试

概述 与其它性能测试工具对比 安装配置 启动方法 使用方法 实例-轻电商搜索接口 背景 测试计划 脚本编写 概述 官网： https://locust.io/ 与其它性能测试工具对比 安装配置 pip install locustio 启动方法 # master locust -f reward_locust.py --master --host= http://jf.baice100.com --web-host=172.31.1.3 # slave locust -f reward_locust.py --slave --master-host=172.31.1.3 使用方法 实例-轻电商搜索接口 背景 测试轻电商搜索接口， http://app.qa.zhengshihui.cn:8000/search/query?pageIndex=1&sortType=smart&pageSize=20&keyword=%E7%9F%AD%E8%A2%96 有一个已知的搜索词列表，每次调用需要随机更改搜索次 请求有固定的header格式 测试计划 整理接口，确认要测试的接口和个性化需求，比如是否需要替换指定参数？对结果是否需要进行特定判断？ 与开发确认测试指标 都要关注那些指标？QPS？平均响应时间？错误率？95% line？ 每一项的标准是什么？达到什么标准算是合格？ 确认测试方法

导读 　　PerfDog（官网： perfdog.qq.com ）作为移动全平台性能测试分析专业工具，在腾讯内部研发测试工具商店-WeTest Store上线后服务了近2000+名开发者，其中《王者荣耀》、《QQ飞车》、《天涯明月刀》、《和平精英》、《使命召唤手游》（CODM）等知名游戏以及QQ浏览器、腾讯微视、微信及小程序小游戏等优秀应用均在使用PerfDog。在经历过腾讯内部性能测试实践后，PerfDog将于2019年11月正式对外发布，开放给全球开发者使用。 洞穿性能测试痛点，铸就性能测试精品工具 　　一年前，PerfDog研发团队在项目研发支持的过程中，频频遇到移动游戏和应用的性能测试问题。例如现有性能测试工具准确性低，带来的大量交叉复测验证、误导分析等额外工作量；又有因为工具局限性和功能空白，不得不同时开启N个工具、进行各式XCode源码编译的困难；再加上iOS系统无法高效进行性能测试和性能分析、以及越狱带来的安全和障碍，移动端性能测试的工作推进变得愈加艰难。 　　在这样的背景下，PerfDog团队决定构建一个不受APP版本、系统版本、系统平台影响，完全独立并且使用简单的性能测试工具。2018年7月，PerfDogv1.0版本开始面向腾讯内部所有团队开放使用。2019年6月，PerfDog上架腾讯WeTest Store面向全公司所有测试及开发者

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）： 并发数： （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS = 1000/(30*60) 事务/秒 并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7 决定系统响应时间要素 我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。 系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间； 关键路径是有CPU运算、IO、外部系统响应等等组成。 二．系统吞吐量评估： 我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。 而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。 通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。 通常的技术方法： A)淘宝 淘宝流量图： B) B2B中文站