沪ICP备3-2016 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd有人会因为无法作出决定就推迟决定，然而实际上推迟决定是最差的决定。在推迟决定期间，时间悄悄流逝，你却没有任何一条路上的积累，白白浪费了时间。来自《暗时间》
&LR中设置pacing值有三种策略。经常用于进行tps的调整。
Iteration，迭代。通过设置，可以指定虚拟用户在同一个Action中重复执行多次，每次重复称之为一个iteration。Iteration可以帮助我们模拟现实世界的重复场景。
Pacing，步调。可以通过设置两次迭代之间的间隔时间，来调整各个action之间的步调（或者称之为节奏）。从定义上来看，Pacing是和iteration绑定在一起的，可以认为是iteration pacing。
&具体策略：
第一项：每次迭代之间无间隔时间。
第二项：每次迭代之间设置固定的间隔时间。即当上次迭代结束后,等待一定时间再进行下次迭代。
从图上，可看出分fixed模式与random两种模式。
fixed即取后边设置的固定时间。
random则事先设置一个范围，取值时随机从范围里取值。
第三项：较为复杂。
从上一次迭代开始到本次迭代开始的时间。
此时和响应时间的关系是：
这种模式的时候理想情况下 &TPS = 1/pacing 值
此种设置要保证pacing值大于&action时间。
如何获取action时间？
http://blog.csdn.net/on_my_way20xx/article/details/
1. & action执行时间 和 业务时间 和响应时间的区别?
& &业务时间 是从lr_start_transaction &到 lr_end_transaction的时间
& &action执行的时间 粗略的说是整个脚本的执行时间(涵盖业务时间)
& 响应时间 = 业务时间 +传输时间+服务器损耗时间等多种 通常情况下我们认为 响应时间=业务时间
2. 如何计算action时间?
& &(1) &注释lr_start_transaction &和lr_end_transaction
& &(2) &启用自动transaction
& & &runtime-setting中设置:
(3) 设置单用户、无pacing值得情况下 跑下场景，此时的action响应时间就是action时间
参考文章：/html/36/n-170436.html
阅读(...) 评论() &我所理解的性能测试是什么？_马哥Linux运维_传送门
我所理解的性能测试是什么？
马哥Linux运维
从朋友圈进来的各位大侠：快猛点↑顶部蓝字「马哥linux运维」关注我们就可以每天收到最新最快最前沿的运维资讯，绝对够味~扯淡首先说明这篇博客是文不对题的。起这个名字想法来源自韩寒的《我所理解的生活》，之前看过一个关于这本书的视频，感觉巨牛X，于是就想写一篇《我所理解的性能测试》。虽然是文不对题的，但我就是想用这个名字，在这个残忍的社会，给自己博客文章起个名字这点权利还是有的。下面我要贴出来的是zee大神的《性能测试面试问题列表》中列出来的性能测试与操作系统方面问题与我自己整理的回答。回答的不一定对，也懒得去改了。就用这些问题与回答来记录我这段时间的努力，来记录我所理解的性能测试吧。性能测试1.如何理解TPS性能指标的一个重要因素。TPS(Transaction Per Second，每秒事物数)，单位时间内完成的事物的数量。TPS的计算一般是通过的事物除以时间。TPS是跟测试脚本中事物(Transaction)相关联的。在性能测试工具中，吞吐量也被称之为TPS(Transaction Per Second，每秒事物数)。吞吐量直接体现系统性能的承载能力，是指单位时间内处理的客户请求的数量。其计量单位可以根据需求不同而不同，比如请求数/秒，页面数/秒，业务数/小时(可以说下我们采集项目中吞吐量可以用 解析卡数/秒)。对于交互式应用，用户直接的体验就是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划;但对于非交互式应用，用“吞吐量”来描述用户对系统的性能期望可能更加合理。吞吐量作为性能测试的主要关键指标。吞吐量和并发用户数之前存在着一定的联系。在没有性能瓶颈的时候，吞吐量随着虚拟用户数的增加而增加(计算公式为 吞吐量 = (VU个数 * 每个VU发出请求数) / 单位时间)。如果性能遇到瓶颈，吞吐量与VU数理之间就不再符合这个关系。2.如何理解线程调用线程(thread)是”进程”中某个单一顺序的控制流。也被称为轻量进程。线程的好处：1) 创建一个新线程花费的时间少。2).(JAVA中线程具有新的，可运行，运行，等待/阻塞/休眠，死亡等几种状态。)在未阻塞情况下，两个线程(在同一进程中的)的切换时间少。在阻塞情况下，线程间切换将产生上下文切换。3).由于同一个进程内的线程共享内存和文件，所以线程之间互相通信不必调用内核。4) 线程能独立执行，能充分利用和发挥处理机与外围设备并行工作的能力。使用线程可以把占据长时间的程序中的任务放到后台去处理ps:JAVA中可以通过jstack或者jprofiler dump出线程所执行的堆栈信息。3.如何理解响应时间响应时间反映完成某个业务所需要的时间。在性能测试中是通过测试工具的事物函数来完成响应时间的统计。事物函数会记录开始事物和结束事物的时间差，使用Transaction Response Time这个词来说明。响应时间主要包括网络时间，服务器处理时间，网络延迟对于交互式应用，用户直接的体验就是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划;对于交互式应用，响应时间出现拐点系统就可能出现瓶颈4.如何理解响应时间，TPS曲线和用户之间的关系随着用户数量的增加，在未出现瓶颈前响应时间保持稳定，TPS值和并发用户数成线性关系，出现瓶颈后响应时间变长，TPS基本保持不变或开始下降。5.在LoadRunner中为何要设置思考时间和pacing?1)Think time，思考时间。可以通过设置思考时间，来模拟真实用户在操作过程中的等待时间。从定义上来看，think time是在iteration内部的某个action中各个步骤的间隔时间。2)Pacing，步调。可以通过设置两次迭代(iteration)之间的间隔时间，来调整各个action之间的步调(或者称之为节奏)。3)pacing和think time都是可以模拟现实世界中的停顿。对于复杂场景，这个停顿要靠pacing来完成。不过，pacing怎么设置才最合适，是需要研究用户行为才能定的。操作系统1.如何判断CPU、内存、磁盘的瓶颈?CPU瓶颈：1) 查看CPU利用率。建议CPU指标如下a) User Time：65%～70%b) System Time：30%～35%c) Idle：0%～5%如果us,sy高于这个指标可以判断CPU有瓶颈使用top查看查看运行队列每个CPU都会维持一个运行队列，理想情况下，调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载，就会出现调度器跟不上系统的要求，导致可运行的进程会填满队列。队列愈大，程序执行时间就愈长。“load”用来表示运行队列，用top 命令我们可以看到CPU一分钟，5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00，那么说明CPU已经超出负荷，交通严重的拥堵。使用top或者uptime查看查看上下文切换每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程，Linux采用抢占式调度。即为每个线程分配一定的执行时间，当到达执行时间，线程中有IO阻塞或高优先级线程要执行时，Linux将切换执行的线程，在切换时要存储目前线程的执行状态，并恢复要执行的线程状态，这个过程称之为上下文切换。对于java应用，典型的是在进行文件IO操作，网络IO操作，锁等待或线程sleep时，当前线程会进入阻塞或者休眠状态，从而触发上下文切换，上下文切换过多会造成内核占用过多的CPU使用，使得应用的响应速度下降。使用vmstat查看cs结论：检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.确定CPU 利用率中user/system比例维持在70/30#p#分页标题#e#当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级当I/O 处理得到增长,CPU 范畴的应用处理将受到影响ps:对于JAVA应用，CPU瓶颈可以通过jprofiler监控分析内存瓶颈：1.查看利用率(free)used:已使用多大。free:可用有多少。Shared:多个进程共享的内存总额。Buffers/cached:磁盘缓存的大小。2.查看页交换，swap交换(po,pi,so,si)，磁盘IO(vmstat)si: 每秒从交换区写到内存的大小so: 每秒写入交换区的内存大小page in :分页(Page)从磁盘重新回到内存的过程被称作Page-Inpage out : 分页(Page)写入磁盘的过程被称作Page-Out另外在进行页交换的时候，会产生磁盘IO，还需注意bi,boBo 磁盘块页面从内存到文件或交换设备的总额Bi 磁盘块页面从文件或交换设备到内存的总额3.page fault(pidstat -r，sar -B )minflt/s: 每秒次缺页错误次数(minor page faults)，次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数majflt/s: 每秒主缺页错误次数(major page faults)，当虚拟内存地址映射成物理内存地址时，相应的page在swap中，这样的page fault为major page fault，一般在内存使用紧张时产生其中sar -B中fault/s表示每秒钟minflt，majflt的和。结论：监控虚拟内存性能由以下几个部分组成：1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.zee：如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加，而空闲的物理内存(free)不断地减少，证明系统中运行的进程正在不断地消耗物理内存。已经使用的虚拟内存(swpd)不断增加，而且存在着大量的页面交换(si和so)，证明物理内存已经不能满足系统需求，系统必须把物理内存的页面交换到磁盘中去。由此可以得到这样的结论：该主机上的物理内存已经不能满足系统运行的需要，内存已成为该系统性能的一个瓶颈。ps:对于java程序，内存瓶颈可以通过heap dump后使用mat分析磁盘瓶颈：iostat查看IO信息。如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。另外还需要注意iowait这个值，iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.ps:磁盘瓶颈可以通过pidstat -d 定位程序2.如何理解CPU、内存、磁盘的关系?这些子系统之间关系是彼此联系，相互彼此依赖的1.对于进程来说，数据是存放在内存中的，进程的运行需要使用CPU，进程读写数据需要跟磁盘打交道。2.当内存不足时需要跟磁盘进行页(page)交换，swap交换，从而产生磁盘IO。po,so释放物理内存，pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)3.当磁盘IO负载过高时，需要监控swap和系统分区，要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的，当iowait 增长,表示CPU花费大量的时间在等待磁盘IO，此时CPU Bound的应用处理将受到影响(磁盘IO过高)3.如何理解paging in / paging out ?在Linux内存管理中，主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上，把活动页面保留在内存中供进程使用。交换技术是将整个进程，而不是部分页面，全部交换到磁盘上。分页(Page)写入磁盘的过程被称作Page-Out，分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时，但发现此分页不在物理内存中(因为已经被Page-Out了)，此时就发生了分页错误(Page Fault)。当系统内核发现可运行内存变少时，就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生，但是如果Page-out频繁不断的发生，直到当内核管理分页的时间超过运行程式的时间时，系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态，这种状态亦被称作thrashing(颠簸)。可以通过vmstat -s 查看 paged in/out 数量4.如何监控操作系统的资源?(可用一个操作系统做例子)(把简历上部分内容直接贴出来了，懒的整理了)CPU监控：top(利用率)， uptime(运行队列数)， vmstat(上下文切换数)， jprofile(方法占用cpu时间百分比)内存监控:top， free(利用率)， vmstat(page和swap交换)， pidstat -r和sar -B(page fault)， jmap -heap(堆dump)， mat和jprofiler(查看对象)磁盘监控：iostat(%util)， top(iowait%)， pidstat -d网络监控：netstat(连接数)， nethogs(流量)， wireshark和tcpdump(抓包)JVM监控：jstat(gc)， jmap(堆dump)， jstack(线程dump)， jprofiler和visualvm(剖析工具)nmon(长时间全局收集数据)5.如何理解上下文切换(context switch)?(可用一个操作系统做例子)每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程，Linux采用抢占式调度。即为每个线程分配一定的执行时间，当到达执行时间，线程中有IO阻塞或高优先级线程要执行时，Linux将切换执行的线程，在切换时要存储目前线程的执行状态，并恢复要执行的线程状态，这个过程称之为上下文切换。对于java应用，典型的是在进行文件IO操作，网络IO操作，锁等待或线程sleep时，当前线程会进入阻塞或者休眠状态，从而触发上下文切换，上下文切换过多会造成内核占用过多的CPU使用，使得应用的响应速度下降。#p#分页标题#e#vmstat其中cs那一列6.如何理解磁盘IO?(可用一个操作系统做例子)磁盘IO速度是非常慢的，linux内核就是要尽量降低IO内存不足时会进行页交换，产生磁盘IOCPU Bound类型应用，当磁盘IO过多，iowait过大时会影响性能。PS:一句话说出我所理解的性能测试，我现在的回答是——果与因
-----The End-----【新朋友】请点击标题下方的“马哥Linux运维”关注！【老朋友】请点击右上角，分享到朋友圈。【马哥Linux运维】专注分享Linux最新资讯。
觉得不错，分享给更多人看到
马哥Linux运维 微信二维码
分享这篇文章
马哥Linux运维 最新文章
马哥Linux运维 热门文章从业务到测试模型_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
从业务到测试模型
上传于||文档简介
&&性​能​测​试​中​我​们​到​底​要​测​试​哪​个​指​标​。​如​何​筛​选​业​务​模​型​,​当​确​定​业​务​模​型​后​如​何​从​业​务​模​型​到​测​试​模​型​。
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩21页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢最近项目中遇到相关性能测试不同方法产生的争议，我这就这个问题在测试环境做了个实验，得出一些指标数据间的有趣关系，供大家讨论学习：
预备知识点：
业界有个TPS ,ART和实际并发量三者间的模拟换算公式：U实际并发量=TPS*ART均值
LR有个.net4.0的计数器Request Current能反应实际的测试过程中实际的PV/s量
设置迭代pacing time情况：
请求用户数：15;&&& &pacing time:3s;&& 理论PV：15/3=5;&&&
TPS:3.4;& ART：1.4&& Request Current:4.6& U并发=TPS*ART=3.4*1.4=4.76
请求用户数：75;&&& &pacing time:15s;&& 理论PV：75/15=5;&&&
TPS:4.5;& ART：1.5&& Request Current:6.6& U并发=TPS*ART=4.5*1.5=6.75
请求用户数：100;&&& pacing time:20s;&& 理论PV：100/20=5;&&&
TPS:4.5;& ART：1.6&& Request Current:6.9& U并发=TPS*ART=4.5*1.5=7.2
1.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,而在有pacing time情况下理论PV和实际PV是随着模拟请求用户数的变化两者的差别变化也是较大，有交集但不同步变化，这个方式不可以预见实际并发量，只能通过测试结果来判断大概的实际并发量，但可以很好的控制模拟请求。
无思考时间和无迭代pacing time情况：
请求用户数：5;&&& &&&pacing time:无;&& 理论PV：5;&&&
TPS:3.56;& ART：1.4&& Request Current:4.75& U并发=TPS*ART=3.56*1.4=4.98
请求用户数：10;&&& &&pacing time:无;&& 理论PV：10;&&&
TPS:7.69;& ART1.3：&& Request Current:9.4 &&U并发=TPS*ART=7.69*1.3=9.99
请求用户数：15;&&& &&pacing time:无;&& 理论PV：15;&&&
TPS:8.4;& ART：1.7& &&Request Current:14.4& &U并发=TPS*ART=8.4*1.7=14.28
2.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,并且在无pacing time和思考时间情况下理论PV和实际PV和实际并发量几乎同步保持一致（我们目前大多数情况采用的都是这个方式压测）。
这里只针对一个transaction对应一个URL请求的情况，特别是接口类的。
其实两个方法都是性能测试中针对不同测试目的而使用的，各有特点。
阅读(...) 评论()}