性能测试

今天在网络上看到了一篇关于 Scala 和 java 多线程对比的文章《 Simple Scala actor Vs java Thread Vs Kilim Test ， 原文链接： http://www.blogjava.net/BlueDavy/archive/2009/11/25/303662.html 。 》，乍看起来似乎是证明了 Scala 在多核处理性能上要强于 Java ，但经过我的分析和测试，发现结果并不靠谱。 这篇文章的作者知识面挺广的，写了 3 个版本的性能对比代码，并且得出了 Scala 在多核处理性能上要强于 Java 。但我要说的是这篇文章所得到的测试结果很不客观，因为里面所用的数据结构和算法有很大问题。 问题一， 1000 次循环里，居然拿 java 里面的 ArrayList 和 Scala 里面的数组比对性能，这是很致命的失误。从理论和实际情况看，数组本来就比 ArrayList 性能强很多倍。 问题二， scala 版本的 1000 次循环居然使用性能很烂的 for 循环，而不是性能更好的 while ，真是无语呀。 问题三， 1000 次循环里， java 版本里很耗时的一个动作是 String.valueOf(i); 看起来和 Scala 版本里面的 i.toString 相似，但实际上，这两种语言里面的内部实现是不同的。尤其是 java

sysbench 是一个非常经典的综合性能测试工具，通常都用它来做数据库的性能压测，但也可以用来做CPU，IO的性能测试。而对于IO测试，不是很推荐sysbench，倒不是说它有错误，工具本身没有任何问题，它的测试方法导致测试的数据会让人有些困惑：性能数据到底是不是这样呢，跟云厂商承诺的性能有关系嘛。一般我们都用FIO来进行性能测试，云厂商都推荐用FIO进行性能测试，通过FIO性能测试，都能轻易达到云厂商承诺的性能。 插曲：关于sysbench的版本，现在主要有0.4.12和1.0.版本。截止2006年sysbench好长时间没有发展，2017年之前都是用旧版本0.4.12（所以网上一搜一大堆文章都是0.4.的教程），然后作者估计修了几个bug，变成0.5版本，然后就跟过去做了告别，从2017重新开发了一个新版本sysbench 1.0.*，这里讲述的性能测试都是用了最新版。 1. sysbench fileio测试 言归正传，sysbench怎么做IO的性能测试呢， sysbench fileio help ,参数如下： #/usr/local/sysbench_1/bin/sysbench fileio help sysbench 1.0.9 (using bundled LuaJIT 2.1.0-beta2) fileio options: --file-num=N

软件性能术语 软件性能的主要术语 用户数 注册用户数（系统用户数） 在线用户 并发用户 虚拟用户 事务（TPS） 响应时间 QPS PV（Page View） 思考时间 吞吐量（一般指字节） 吞吐率（一般指字节） 性能计数器 软件性能非主要术语 集合点 迭代 步调 每秒连接数 软件性能的主要术语 用户数 有时会看到下面这样的描述：一个系统注册用户达到6000万人，其中每小时的活跃用户大概在60万人左右。这段描述介绍了两个信息，第一个信息：6000万人指的是注册用户，第二个信息：60万人指的是真实在线用户。 注册用户数（系统用户数） 注册用户是存在于系统数据库表中的基础数据。这部分用户是指系统所拥有的所有用户群体。这些用户是不会全部对系统造成压力的，唯一的压力就是这些用户占用了系统的存储，影响了数据库的容量。 在线用户 在线用户是真实产生压力的用户，这些用户是压力的根源，也就是系统要能够支持这么多人同时在线业务。 同时在线用户数：在一定的时间范围内，最大的同时在线用户数量 同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间 并发用户 在线用户是真实的用户，但不是所有的在线用户都会在系统上操作，可能有些用户在浏览网页、有些用户在做业务、有些用户只是开着浏览器。这时在线用户对系统产生压力的用户只有一部分，而这部分用户就是在线用户中的有效并发用户。

最近有些同学找我咨询关于性能测试计划相关的问题，原因是他们公司要做性能测试，Leader要求写一份性能测试计划，苦于之前没做过相关工作，无从下手。 这篇博客，结合我个人的一些经验和总结，聊聊如何制定一份较为全面的性能测试计划。。。 一、测试背景 首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。 比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。 核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。 二、测试目的 测试的目的要根据测试背景来分析设定，比如： 1、线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证； 2、运营做了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否满足新的线上业务； 3、系统架构由集群技改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据； 三、测试范围 通过需求调研，分析用户使用场景，对业务数据量增长变化趋势及峰值活跃用户等数据做定量分析，确定被测系统的应用范围，比如订单+购物车+商品+支付服务。 业务归属模块 业务涉及场景 订单 创建订单 取消订单 购物车 添加购物车 删除购物车 商品 商品列表 商品详情 支付 余额支付 支付宝支付 微信支付 四、术语约定

一、概述 检查点是所有类型的测试中的核心 做过自动化测试的同学应该心中都有一个概念，没有校验的自动化测试用例是没有意义的，我认为性能测试上也同样如此，加入不能保证操作的有效性，哪有何谈测试该操作造成的负载呢？所以我们需要再性能测试脚本中加入检查点功能。 检查点是一种概念，是为了确认我的操作真的成功了。从页面中提取某些信息，并和预期校对、探测页面有没有发生一些新的事件、甚至仅仅是在完成特定步骤后截图人工查看都算是检查点，在loadrunner中，检查点主要以文本的形式体现 二、在录制时加入检查点 来源： https://www.cnblogs.com/buzileblog/p/11328294.html

近期接触了支付场景的性能测试，发现了很多严重的并发问题，要不是有性能测试，对公司会造成很大的损失： 1、钱不够时候，能否支付成功？ 比如：卡余额有100块钱，10并发循环20次，由200笔请求，会生成100笔支付成功的订单，96笔支付失败的订单，以及生成4笔失败的订单，为什么呢?因为生成的四笔失败订单是临界点的。 2、库存不够时候，能否支付成功。 3、没钱时候，能否支付成功。 来源： https://blog.csdn.net/hello_world_zhao/article/details/98763544

　　Redis 性能测试是通过同时执行多个命令实现的。 　　语法 　　redis 性能测试的基本命令如下： 　　redis-benchmark [option] [option value] 　　实例 　　以下实例同时执行 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 second 　　LRANGE_100 (first

原文转自：https://blog.csdn.net/lovesoo/article/details/78579547 Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件。相比Loadrunner而言，JMeter小巧轻便且免费，逐渐成为了主流的性能测试工具，是每个测试人员都必须要掌握的工具之一。 本文为JMeter性能测试完整入门篇，从Jmeter下载安装到编写一个完整性能测试脚本、最终执行性能测试并分析性能测试结果。 运行环境为Windows 10系统，JDK版本为1.8，JMeter版本为3.3。 2. Jmeter安装 2.1 JDK安装 由于Jmeter是基于java开发，首先需要下载安装JDK （目前JMeter只支持到Java 8，尚不支持 Java 9） 1. 官网下载地址： http://www.oracle.com/technetwork/java/javase/downloads/index.html 2. 选择Java SE 8u151/ 8u152，点击JDK下载 3. 安装下载的JDK 4. 配置系统环境变量 2.2 JMeter安装 官网下载地址： http://jmeter.apache.org/download_jmeter.cgi 下载最新JMeter 3.3版本：apache-jmeter-3.3.zip

 最近性能压测执行过程中，经常看到很多测试人员执行性能测试，要寻找拐点，但是效率太低，本文就介绍下，如何高效确定性能测试拐点  所谓性能测试拐点，就是指并发用户达到一定数量，平均响应时间递增，TPS不增反降，报错率递增，当前并发用户就是该测试案例的拐点    寻找拐点的意义就是当前并发用户下，系统的平均响应时间、TPS、报错率是否满足性能要求，如果满足，该并发用户就是满足用户需求下所能承受的最大并发用户数，在去考虑并发用户是否满足系统用户需求，可以结合系统总用户数、在线用户数去判断，他们的关系大致如下： 在线用户数=系统总用户数*20% 并发用户数=在线用户数*30% 比如系统总用户数是10000，则在线用户数就是2000，并发用户数就是600 一、脚本开发 1. 首先给大家介绍如何开发高效执行的性能测试脚本，目前多数用户都是分不同并发用户单次执行，该方法执行效率低，并且不方便数据比对，如下 首先开发好测试案例，然后把案例复制成多个，每个线程修改线程数、用例名称即可，如下所示，修改用例名称和线程数对应，这样生成的测试结果就会区分不同并发下同一个案例的响应时间，方便比对 如果有多个接口实现了一个用例，则需要把所有接口放置在事务控制器下即可，这样就能生成一个汇总结果(统计多个请求的响应时间、tps等值) 最后在测试计划记得勾选独立运行每个线程组选项，勾选该选项的意义就是依次并发执行10

转发自：老张https://www.cnblogs.com/imyalost/p/10850811.html 一、注意事项 1、断言 在压测时，为了判断发送的请求是否成功，一般会通过对请求添加断言来实现。使用断言时，建议遵循如下规范： ①、断言内容尽量以 status/code、msg/message 来判断（当然前提是接口设计遵循Restful规范） Jmeter示例： 阿里云PTS： 如果使用的是PTS压测，则断言设置中，以code/status、msg/message 等于 对应的值为准； ②、尽可能 不要将所有的Response Body内容作为断言判断的内容 ，这样很可能会导致大量的“断言”失败； PS：然后很遗憾的是，见过很多做压测的童鞋，断言内容以整个响应参数内容做断言，导致大量的报错。 2、成功率 一般在性能测试中，我们都追求99.99%的成功率，但在实际的测试过程中，为了尽可能覆盖代码逻辑，在准备阶段会尽可能的准备较多的热点数据去做到覆盖。 这样的话，我们所关注的成功率指标，就要分为如下两种： ①、事务成功率 事务成功率在某些时候也可以视为请求成功率，在断言判断时以code/status等内容来作为请求是否成功的衡量依据； ②、业务成功率 实际的业务场景中，所谓的成功率，并不能仅根据返回的code/status来判断。比如：一个查询请求