响应时间

本次性能测试的需求中提到测试的目的是“了解博客的首页在负载达到20 QPS时的响应时间”，因此需要控制向博客首页发送请求的负载为20QPS。 　　一种可行的方法是逐步调整测试计划中的线程计算的数量以及为取样器（Sampler）添加定时器（Timer），以使HTTP取样器发出的请求的QPS保持在20个左右。但这种方法耗时耗力，需要经过多次尝试才能达到；另一方法，完全通过设置定时器来控制QPS，一旦取样器的响应时间发生改变（网络环境发生改变），就需要重新调整定时器的等待时间。 　　Jmeter提供了一个非常有用的定时器，称为Constant Throughput Timer （常数吞吐量定时器），该定时器可以方便地控制给定的取样器发送请求的吞吐量。 　　右键点击fnng.cnblogs.com ，弹出菜单（添加--->定时器--->Constant Throughput Timer）选择Constant Throughput Timer Constant Throughput Timer 的主要属性介绍： 名称 ：定时器的名称 Target throughput（in samples per minute） ：目标吞吐量。注意这里是每分钟发送的请求数，因此，对应测试需求中所要求的20 QPS ，这里的值应该是1200 。 Calculate Throughput based on

一、关于数据库性能分析 数据库服务器的性能： 我们将 性能定义为完成某件任务所需要的时间 ，性能即 响应时间 ，这是应该很重要的原则， 我们通过任务的响应时间而不是资源来测量时间。 性能：即完成任务的响应时间,单位时每个任务花费的时间。 任务：查询或者语句，如SELECT、UPDATE、DELETE。 所以 我们优化时，首先要知道，时间花在哪些地方 。这是第二个原则。 性能剖析： 任务花费时间分为：执行时间和的等待时间。 优化执行时间：通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务，降低子任务的执行频率或者提升子任务的效率。 等待时间：多种原因引起，分析更为复杂。 性能剖析的一般步骤： 1.测量所花费的时间，使用查询日志。 2.然后对结果进行统计和排序，将重要的任务排到前面。 1.采集查询日志 我们如果要测量查询语句所花费的时间，就要捕获Mysql的查询到日志文件中。 Mysql为我们提高了以下的日志来捕获查询： 慢查询日志：io开销低，测量精度最高的查询时间的工具。 通用日志：很少用于分析查询，不包含响应时间和执行计划。 注意：长期开启慢日志，需要消耗大量的磁盘空间，需要部署日志轮转工具，或者只在需要采集查询的时候开启。 Mysql5.1及以后的版本，可以通过设置long_query_time为0来捕获所有的查询，查询的响应单位为微秒级。 2.分析查询日志 分析时

AggregateReport 是 JMeter 常用的一个 Listener，中文被翻译为“聚合报告”。 ​ 对于每个请求，它统计响应信息并提供请求数，平均值，最大，最小值，错误率，大约吞吐量(以请求数/秒为单位)和以kb/秒为单位的吞吐量. 聚合报告下方的图是对上方的表的一个可视化，所以在这里我们主要解释每一个表项是什么意思。 Label: 请求的名称，就是我们在进行测试的httprequest sampler的名称 Samples: 总共发给服务器的请求数量，如果模拟10个用户，每个用户迭代10次，那么总的请求数为：10*10 =100次； Average: 默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，以Transaction 为单位显示平均响应时间 ，单位是毫秒 Median: 50%用户的请求的响应时间，中位数 90%Line: 90%的请求的响应时间 95%Line: 95%的请求的响应时间 99%Line: 99%的请求的响应时间 Min: 最小的响应时间 Max: 最大的响应时间 Error%: 错误率=错误的请求的数量/请求的总数 Throughput: 默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似

性能测试 工程师基本上都能够掌握利用测试工具来作负载、 压力测试 ，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人 工作 中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。 分析原则： 1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 2. 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器 操作系统 瓶颈（参数配置）-〉中间件瓶颈（参数配置， 数据库 ， web 服务器等）-〉应用瓶颈（ SQL 语句、数据库设计、业务逻辑、算法等） 注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 3 分段排除法 很有效 分析的信息来源： 1 根据场景运行过程中的错误提示信息 2 根据测试结果收集到的监控指标数据 一．错误提示分析 分析实例： 1 Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection Error: timed out Error: Server “10.10.10.30″ has shut down the connection

1. 官网下载Jmeter: 点这里 , 下载完成解压即可 2. 启动: 进入解压后的bin目录, Windows点击jmeter.bat, Linux执行jmeter 3. 添加线程组(user) : Test Plan --> Add --> Threads(Users) --> Thread Group, 这里还有setUp Thread Group和tearDown Thread Group, 前者是测试之前做的事, 后者是测试之后做的事. 这里点击Test Plan有个执行计划的设置比较常用, Run Thread Groups consecutively(i.e.one at time), 勾选表示顺序执行, 指的是测试计划中存在多个线程组时，第一个线程组执行完后再执行下一个线程组。下图是线程组的线程配置详情: 4. 这里介绍常用的几个, 有些不常用的需要用的时候, 自己去试一下或者找下资料看下文档说明. 　　Sampler: 常用的HTTP Request/FTP Request/JDBC Request/Java Request, 这个是核心元件, 具体测试的对象在这里写, 基本用到的HTTP Request, post/get的HTTP请求, 这里懂HTTP协议的一看就会了, 需要注意的是编码(有时候会乱码), Redirect

1. 官网下载Jmeter: 点这里 , 下载完成解压即可 2. 启动: 进入解压后的bin目录, Windows点击jmeter.bat, Linux执行jmeter 3. 添加线程组(user) : Test Plan --> Add --> Threads(Users) --> Thread Group, 这里还有setUp Thread Group和tearDown Thread Group, 前者是测试之前做的事, 后者是测试之后做的事. 这里点击Test Plan有个执行计划的设置比较常用, Run Thread Groups consecutively(i.e.one at time), 勾选表示顺序执行, 指的是测试计划中存在多个线程组时，第一个线程组执行完后再执行下一个线程组。下图是线程组的线程配置详情: 4. 这里介绍常用的几个, 有些不常用的需要用的时候, 自己去试一下或者找下资料看下文档说明. 　　Sampler: 常用的HTTP Request/FTP Request/JDBC Request/Java Request, 这个是核心元件, 具体测试的对象在这里写, 基本用到的HTTP Request, post/get的HTTP请求, 这里懂HTTP协议的一看就会了, 需要注意的是编码(有时候会乱码), Redirect

http_load是基于linux平台的性能测试工具，它体积非常小，仅100KB。它以并行复用的方式运行，可以测试web服务器的吞吐量与负载。 一、安装http_load A、进入/usr/local目录下创建man文件夹，并赋予权限； [root@localhost ~]#cd /usr/local [root@localhost local]#mkdir man [root@localhost local]#chmod 777 man B、进man文件夹中，下载http_load安装包； [root@localhost local]#cd man [root@localhost man]# wget http://acme.com/software/http_load/http_load-12mar2006.tar.gz C、解压、并安装http_load-12mar2006.tar.gz包； [root@localhost man]# tar zxvf http_load-12mar2006.tar.gz [root@localhost man]# cd http_load-12mar2006 [root@localhost http_load-12mar2006]# make [root@localhost http_load-12mar2006]# sudo make

概述 jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈 本文以500线程的阶梯加压测试结果来描述图表。 常用监听器 1：Transactions per Second 监听动态TPS，用来分析吞吐量。 其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。 最大TPS大约在140左右，从1分26秒左右，开始有未通过的事物 2：Hits per Second 动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。 点击率波动较大，且不能持续上升。说明性能很不稳定 3：Response Times Over Time 监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒） 响应时间在4950ms左右开始稳定下来，后续又经历一次大的波动 4：Response Times vs Threads 线程活动期间的响应时间监听。其中横坐标是活动的线程数（也就是并发数），纵坐标是响应时间（单位是毫秒） 5： Active Threads Over Time 监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数） 6：Response Times Percentiles 监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间

2 PerfMon Metrics Collector 用于监控机器的 CPU，Memory，SWAP，Disks I/O，Networks I/O CPU CPU 占用量百分比 Memory 存储量的使用情况 SWAP Disks I/O Networks I/O 3 Server Hits per Seconds 每秒测试计划所产生的点击服务器的次数 4 Bytes Throughput Over Time 在压力测试期间接收和发送的 bytes 数 5 Composite Timeline Graph 将你的测试计划中的所有的图表集合在同一张图标中以方便查看 6 Bytes Throughput Over Time 每秒传输字节吞吐量，表明 Jmeter 在测试时，随着时间推移发送和接受的字节数 7 Response Codes per Second 每秒返回的响应码，表明 Jmeter 测试期间，随着时间的推移返回的响应码，从中我们可 看到测试期间在哪个时间段内出现了错误。就可以分析在该时间内系统的什么环境因素， 导致的错误。 8 Response Latencies Over Time 每秒钟的响应等待时间， 表明 Jmeter 测试期间，随着时间的推移系统的响应等待时间的 变化，也是系统随着时间推移，系统效率的变化。 9 Response Times

使用方法： 1、添加线程组——jp@gc - Stepping Thread Group 2、Stepping Thread Group界面如下： 上图的各项意思： This group will start 100 threads：设置线程组启动的线程总数为100个； First,wait for N seconds：启动第一个线程之前，需要等待N秒； Then start N threads：设置最开始时启动N个线程； Next,add 10 threads every 30 seconds,using ramp-up 5 seconds：每隔30秒，启动10个线程，10个线程在5秒内启动完成； Then hold load for 60 seconds：启动的线程总数达到最大值之后，再持续运行60秒； Finally,stop 5 threads every 1 seconds：每秒停止5个线程； 这里是对每个插件的用处进行解释： PerfMon Metrics Collector：用于监控机器的CPU、Memory、swap、Disks I/O、Networks I/O。CPU：cpu占用量百分比； Memory：存储量的使用情况；swap：交换区的使用情况；Disks I/O：磁盘I/O；Networks I/O：网络I/O Hits per Second