Posted on 2006-12-04 00:27
Jackei 阅读(10677)
评论(71) 编辑 收藏 所属分类:
04.软件性能测试 、
00.置顶推荐
两个新的系列文章的写作计划——《LoadRunner 没有告诉你的》和《JMeter从入门到精通》
到DMX整整一年了，相比2005年，最大的变化就是工作和研究的重心从测试组织的建立和团队管理转移到了性能测试和软件测试自动化方面。随着研究和实践的不断深入，沉积下来的东西越来越多，各种新的想法和思路也像“井喷”一般地冒出来，创作的欲望也随之而来。
目前考虑会将文章分为《LoadRunner 没有告诉你的》和《JMeter从入门到精通》两个系列。
《LoadRunner 没有告诉你的》会包含一系列讲解性能测试本质和最佳实践的文章，其中有些内容是与工具无关的，有些则是内功心法，练好了用哪个工具都能杀人于无形^_^目的是尽可能的帮助大家更准确的理解性能测试，少走弯路。
而《JMeter从入门到精通》则完全关注于JMeter(一款在国外非常流行和受欢迎的开源测试工具)在性能测试工作中的应用，其中有些内容或许会于《LoadRunner 没有告诉你的》系列有些交叉。我并不是一个狂热的“开源分子”，但是我会非常乐意提供一系列完整的JMeter中文指南，来帮助那些需要在工作中使用JMeter的同行“脱离苦海”^_^
下面是这两个系列文章的目录。
《LoadRunner 没有告诉你的》
描述性统计与性能结果分析（已完成）
描述性统计与性能结果分析（续）（已完成）
理发店模型（已完成）
理解性能（已完成）
无处不在的性能测试（已完成）
获取有效的性能需求（已完成）
New!! 使用 LoadRunner 连续长时间执行测试，如何保证参数化的数据足够又不会重复？(已完成)
Std.(标准差) 在性能测试分析中的应用（50％）
踏上设计测试场景的正途
你真的知道该如何执行测试吗？
正确的分析和调优方法
一个性能测试工程师应该了解的数学和统计学知识
你的测试结论是什么？（计划与“正确的分析和调优方法”一文合并）
《JMeter从入门到精通》
开始你的第一个JMeter脚本（已完成）
理解 JMeter 聚合报告（Aggregate Report） (已完成)
[翻译]如何解决使用
JMeter 时遇到的问题（已完成）
使用 JMeter 分布式性能测试（已完成）
使用命令行方式运行
JMeter 脚本（已完成）
使用JMeter测试数据库性能（已完成）
JMeter 测试结果分析入门
JMeter脚本的参数化
理解JMeter中常用的组件
JMeter 测试结果分析详解
如何使用 JMeter
的 Schedule 功能来完成LoadRunner中Controller的功能
没有LoadRunner我们如何获取各种性能计数器的数据？
LoadRunner vs. JMeter
Feedback
也欢迎大家积极参与本次写作的投票活动，您可以选择的包括：
1.非常感兴趣，期待ing
2.有个把主题还有点意思，到时候看看再说
3.没兴趣，都是垃圾
呵呵，可以设计剧情改变人物命运哦 ^_^
期待大戏,以前装过LoadRunner,但实在是不知道怎么用
@Emily wong
@CrazyCoder
@Riancy
@zoe
感谢各位的支持，也希望大家都可以各抒己见，提出自己的疑问和看法 ^_^
非常关注这个方面的内容，现在正在读“关河”写的一本软件性能测试的书，希望能从两位的不同思想碰撞中，吸取到更好的东西。
@heqingbluesky
如果有收获或者想法，也非常希望可以提出来大家一起讨论和交流 ^_^
不知道有没有比较好的进行 “功能测试”的自动化工具？
@Laser.NET
实现功能测试自动化的工具其实很多，不过看你需要的是什么了 ^_^
@Jason Kung
非常感谢，希望不会让你失望 ^_^
拜读了作者的几篇文章，感觉不错；的确是做了不少实际工作，才能沉淀出这些思想。
但是觉着《LoadRunner 没有告诉你的》这一系列规划的写作内容有点散，没有主线；不象是写一个系列的文章，到象是工作日志、学习笔记、随想之类的。
文章的名称也没必要和Lr扯上关系，如果要了解Lr的使用，直接看帮助就可以了，官方网站上也有很多技术文章。重点应该在性能测试本身。
《JMeter从入门到精通》这个系列就没看了。
希望作者再接再励，祝写作顺利！
@sally[匿名]
@Justin
@一颗心的痕迹
@will[匿名]
@cx[匿名]
感谢楼上这么多位的支持 ^_^
最初决定写这两个系列文章，一方面是为了对自己的工作和研究做一个总结，另一方面是因为看到目前国内太多同行过于关注性能测试工具的研究，以对工具研究的深入程度来衡量性能测试的好坏；但是对性能测试本身却缺乏正确的理解，对性能测试过程的各个阶段也缺少深入的思考和系统化的总结。于是，偶斗胆扬起大旗，希望可以通过两个系列文章来转变大家的思路，并目光重新聚焦到性能测试最核心的东西上。——偶在这两个系列的开始，就已经做好了当“烈士”的准备 ^_^
对于《LoadRunner 没有告诉你的》这一系列，最初的想法是包括两个部分，一方面是对性能测试基本概念的理解，另一部分是对于性能测试过程各个阶段实践经验的总结。目的都是想把一些性能测试本质的、与工具无关的东西剥离出来，让大家看的更清楚一些，理解更深入一些。所以包含的内容并不是有关 LR 工具的介绍，或者一些所谓的高级技术的介绍。——不知道这样是否可以解释一下cx 朋友的疑惑 ^_^
偶最近一次使用 LR 做性能测试也是一年前了，在最近这一年中，所有的性能测试工作基本是基于各种开源或免费的工具，以及操作系统、数据库、应用服务器自身包含的方法和工具实现的。在脱离了 LR 以后，反而发现自己离性能测试越来越近。
我并不是说煽动大家放弃 LR 改用其他工具——虽然 LR 的确是可以被替代的——工具本身也不过是测试方案中的一小部分，只要可以帮助我们更快更好的完成工作任务，商业工具还是开源工具，或者找开发人员编写特定的工具都不是问题的关键。
希望大家都把玉抛过来，也希望我们可以通过讨论和交流能挖掘出更多深层次的话题，总结出更多可供其他同行参考的最佳实践。^_^
理发店模型真的很不错，解答我之前的很多问题，谢谢啊。
@janezhang815
You are welcome ^_^
最近在做性能测试方面的工作，一致处于迷茫状态，也读了许多零散的资料。不过今天读了这一系列文章顿觉眼前一亮。有种全新的体会。继续拜读中......
@没刺的仙人掌
呵呵，谢谢您的关注和赞赏。其实自从开始写这些文章，也逐渐和许多朋友讨论到了更多有关性能测试的问题，发现在总结、写作、讨论的过程中，又有了很多新的收获和认识。如果您有兴趣，也可以写一些自己在工作和学习中的心得体会，大家在讨论中可以共同进步的更快。^_^
期待你的后续早点出来。
另：我在博客园的blog也开张了，已经把你的blog地址添加到我的友情链接里了，我也希望你能和我做链接！欢迎多多来交流！^_^
http://www.blogjava.net/xingcyx/
@xingcyx
谢谢关注，有时间多交流 ^_^
@阳光[匿名]
每天都是最合适的那天 ^_^
1.非常感兴趣，期待ing
还期待JMETER尽快退出新内容:)
1.非常感兴趣，期待ing
同时希望是否有后续的QTP和TD一组，
最近在尝试VSTS For Tester中的Web Test和Load Test，希望日后能多多交流。
@blackwind
@greent
@deem
@oscarxie
非常感谢大家的关注和支持。最近一段时间来这两个系列文章的更新近于停滞，一方面是最近这段时间工作的确太忙，另一方面也是因为自从上次准备完了那个“性能测试实践”的PPT后(下载地址
http://www.cnblogs.com/Files/jackei/performance-testing-ppt.zip)，感觉要说的话好像一下都说完了，一下没了创作的激情——对我来说，如果没有了创作的激情，写作就变成了无病呻吟和码字的工作。所以为了避免生产垃圾，干脆暂停了后面内容的更新。还望大家见谅。
But, I'll written other articles ASAP.
In addition, to oscarxie：因为目前工作中使用的测试工具还是以开源工具为主，所以没有机会接触到 QTP和TD。不过以后如果有时间，会逐步写一些 Selenium（可以看过是 QTP 的替代品） 在 Web 测试自动化中的应用，如果有兴趣，大家多多交流 ^_^
既然可以用Loadrunner，就可以用QTP，都是MI的产品，都不是免费的
@华华
呵呵，LoadRunner 主要是在以前的公司和自己在家做试验用的，现在这家公司一直在用 JMeter 和 ab，所以才有了 《JMeter从入门到精通》这个系列，以及另外两篇有关 ab 的介绍 ^_^
Jmeter一系列的文章,我都看了,写的很好.多谢了.希望作者写出更好的文章
@李洪生
呵呵，多谢关注 ^_^
不过最近一个月工作重点转向了自动化测试方面，所以 JMeter 部分的暂时停了下来。我想要等到春节后才有时间继续其他几篇文章了。如果遇到问题，可以留言讨论 ^_^
没有LoadRunner我们如何获取各种性能计数器的数据？
这篇文章什么时候能看到？
loadrunner中不能直接监控tomcat,需要写监控脚本，比较烦琐！
有其它有什么途径能解决？刚接解JMETER还不太了解，请问JMETER可以实现吗？
我也在尝试写一些LoadRunner分析和Controller的文章,我打算按照Analysis系列和Controller系列来进行,目前Analysis已经写了一些了, 希望多跟你交流.
博主，真是高强啊！佩服，佩服！
LoadRunner这两个工具，都尝试过使用，所以很期待您的高见。
@ZR
如果没有 LR，对于 Windows 的监控可以通过系统自带的 Performance Monitor 来实现——在“运行”对话框输入“perfmon”；Linux 下可以使用 sysstat 系列和 top 来实现。
对于应用服务器和web服务器，以及数据库服务器，如果没有自带的监控工具，则需要借助第三方工具来实现，也可以自己写代码来实现。
@eagle
抱歉，因为年前转到自动化测试这边了，所以性能测试方面的总结就告一段落了。推荐一下 Ricky 的blog，也很不错的，对自动化测试和 LR 性能测试有兴趣的朋友不妨关注一下 ^_^
www.rickyzhu.com
《JMeter从入门到精通》，我支持这个系列的文章。很有前途
非常感谢jacky,最近开始做stress testing,对于jmeter方面的文章受益匪浅，但是对于JMeter脚本的参数化比较期待，因为目前遇到这个问题，我还不是太明白怎么操作。如果在线的话，帮忙解答下，多谢，多谢达人！
@Sophie.Rui
推荐看一下 JMeter 帮助手册中的 CSV Data Set Config 组件吧。很简单的。具体也可以参考一下这里
http://www.cnblogs.com/jackei/archive/2007/01/21/626342.html
Hi Jackei,
有个性能测试方面的问题想请教一下，问题是这样的：
假设某个系统中完成某个业务需要由三个子系统来共同完成，SS1(子系统1)业务逻辑较为简单，有一次数据库访问；SS2(子系统2)业务逻辑要复杂很多，算是三倍于SS1的处理复杂度，有4次数据库访问；SS3(子系统3)业务逻辑中等，算是两倍于SS1的处理复杂度，有3次数据库访问。三个子系统在同一千兆局域网内，统一使用WebLogic应用服务器。SS2和SS3采用了集群，分别有3台和2台被管端。
系统对这个业务的性能要求是120TPS，那三个子系统的性能指标分别是多少呢，SS2和SS3的每台被管端的性能指标又是多少？需要考虑哪些损耗？
你应该比较忙，但从博文中可以深深感受到你对知识的探索欲望和分享精神，忍不住想占用你一点点时间，多谢了。
@老院子
您太客气了。看了您的留言，说说我的看法。不知道理解的对不对。
1.您提到“某个系统中完成某个业务需要由三个子系统来共同完成”，不知道这三个字系统在处理过程中是串行还是并行？
2.如果是串行，那么假设每个用户请求都要顺序经过 SS1->SS2->SS3 三个子系统的处理，那么其中响应能力最差的那个就会成为整个业务的瓶颈。建议可以先以整个业务为单位进行考察，在测试过程中不断的增加负载，并观察三个子系统的响应能力变化，找到并优化瓶颈；
3.“三个子系统的性能指标分别是多少呢，SS2和SS3的每台被管端的性能指标又是多少？需要考虑哪些损耗？”——这个应该就是我们要通过测试去找寻答案了。通过不断的增加负载，观察测试过程中吞吐量、响应时间和系统软硬件资源利用率的变化，可以绘制出随负载变化的性能曲线，也帮助我们去分析系统瓶颈和进行优化。例如，先找到哪个子系统是瓶颈，然后分析是应用层还是DB的性能差，然后分析具体的业务逻辑、代码，完成瓶颈的定位和优化。
Hi Jackei,
很高兴看到你的回复。
关于你提到的第一点，三个子系统是属于串行处理流程，就像你假设的那样 每个请求都要顺序经过SS1->SS2->SS3这样的处理。
你说的第二点，我的理解是你建议在系统完成后，通过测试得到各子系统的负载能力，并据此去找出性能瓶颈，经过分析后进行优化。目前的情况是客户对系统已经提出了非功能性需求--具体的性能指标，而各子系统是由不同的厂家完成，先由各厂家单独对自己子系统进行性能测试（相应的上游、下游子系统分别使用模拟器来配合测试，也就是主要测试自己负责的子系统的负载能力，上下游接口的消耗很小，可以认为只有通讯时间，没有处理时间），也就是目前需要根据系统架构来对性能指标进行分解，分摊到各子系统中去，我不知道这样是否可行，可行的话，应该按什么方法来分解。
第三点，其实我是想了解你以前在用集群作负载均衡时的损耗经验值，假设某系统在单机时的性能指标是100TPS，比如按 x*(1-k)*y=100，x为单台被管端承受的压力，k是损耗系数，y是被管端数量（假设单台被管端上只有一个domain，只部署一个应用）。
这么晚还在回答问题，再次让我感动，多谢了！
Hi Jackei
有下面一个分解思路，你看看是否合适：
假设数据库访问操作与简单业务逻辑处理的时间消耗比例为6:1，集群中单机的损耗系数为0.3（实际情况中跟被管端数量以及负载均衡方式，是否使用session复制等有关）
结果分析：SS1、SS2、SS3时间消耗模型为－－(1*6 + 1) : (4*6 + 3) : (3*6 + 2) = 7:27:20
产品需求全流程达到120TPS，则：
SS1(1台机器)=120*(7+27+20)/7=926TPS；
SS2(3台机器)=120*(7+27+20)/27=240TPS；单机=240/3/(1-0.3)=114TPS
SS3(2台机器)=120*(7+27+20)/20=324TPS；单机=324/2(1-0.3)=231TPS
@老院子
呵呵，您太客气了。
白天的时间都是别人的，没法静静的思考问题，不过先针对您上面的回复说说我的看法。有点乱，也不一定对，大家交流一下吧。
我数学不好，所以您上面列出的算法我不是特别明白。不过，上面的讨论中您没有提到两个关键的数据：并发量(负载模型)和响应时间的要求。个人认为有了这两个数据以后再来推算各子系统应该达到的 TPS 值才会更有意义。
另外，如果的确有三个子系统串行处理，那么在负载一定的情况下，三个子系统的响应能力不应该相差太悬殊，否则就表明其中存在某些子系统的资源紧缺或者浪费。所以应该关注在负载一定的情况下，根据您上面提到的算法——应用的时间消耗和数据库访问的时间消耗来推算每个子系统为了达到 TPS 要求，必须满足的响应时间和资源利用率，然后再进行优化。
P.S. 一个系统的性能优化有时并不仅仅依赖于自身代码算法或配置的优化，对于复杂的系统来说，部署方式本身也会影响到系统的性能，各个子系统之间的性能差异有时反而会变成恶性循环。
例如，如果 SS1 的响应能力远远优于SS2，那么在实际应用中可能会导致源源不断的请求被SS1 丢给 SS2，SS2的负载越来越大，超过了所能承受的最大负荷时，反而会导致大量的请求无法被正确处理，也无法转移到下一步SS3那里。在场景中就会看到 SS1飞快的处理着，但是大量的业务超时失败，SS2的各项资源利用超负荷，而SS3却是空闲的。
所以，建议还是三家厂商要预先做一次联调和性能测试，如果直接就上生产环境，风险比较大。
对于“损耗系数”，没有经验，以往对于 LB 的方案是要进行测试和优化的，不过肯定是无法达到随 cluster 增加而线性增长的。这里涉及到的可以优化的东西也比较多，包括 LB 本身的配置，也涉及到部署的策略。如果 Team 中有架构师，可以直接跟架构师聊聊。
也邀请了更多的朋友来参与讨论，希望听听大家的看法。
Hi Jackei,
首先非常感谢你的回复，呵呵，光从回复的字数来看就可感觉到你的不吝赐教，thanks again.
很抱歉，之前只是简单的考虑看看是否能将性能指标在多个串行子系统之间进行分解，因此没有提供具体的并发量和响应时间以及系统的一些其他数据，这里补充一下，100个并发用户，响应时间不超过1.2S，每日处理80W条左右的业务，系统每日运行时间8小时。
另外，你提到的子系统之间的短板效应，我很赞同。但从另外一个角度来看，系统的响应时间短，那它的事务处理能力（吞吐量）就强，这两者本身就存在一定的正比关系。并且在不断增加请求时，如果没有超出其并发量（可以认为是不断增加并发用户数，在达到最佳并发用户数之前），响应时间的曲线通常会较为平稳。
PS：如果按时间消耗的分配来算的话，按照前面估算的SS1:SS2:SS3=7:27:20，三个子系统串行来消耗这1.2S的话：
SS1消耗的时间：0.16S
SS2消耗的时间：0.6S
SS3消耗的时间：0.44S
按100个并发用户，每次请求都是单独一个事务来简单估算的话：
SS1的吞吐量： 100/0.16=625
SS2的吞吐量： 100/0.6=167
SS3的吞吐量： 100/0.44=227
（从历史数据看来，实际的吞吐量会低于并发量与响应时间的商）
你提到的这个短板效应启发我了我另外一个思路，可以先算出时间消耗最大的SS2的吞吐量，另外两个子系统主要是在100个并发用户下的响应时间不大于相应的比例（0.16S和0.44S），其吞吐量不小于SS2的吞吐量就可以满足整个系统在并发量和响应时间上的要求了。
上面只是自己的一些简单想法，有可能是错误的（为了缩小我们讨论话题的范围，暂时就不讨论性能优化问题，主要是对性能需求开发、性能指标的确定等方面做一些探讨），想继续听听你和大家的建议，谢谢。
Sorry, 上面笔误，响应时间与吞吐量应该是反比关系。
@老院子
呵呵，您的回复比我专业，不过粗看起来应该没有分歧。等我晚上回去好好想想再继续 :)
Hi Jackei,
你谦虚了，你的文笔和专业知识远胜于我，有机会多向你学习。
两位的讨论都很精彩，我也看看我的看法。
首先我觉得老院子对3个子系统的时间消耗模型理论上来说应该可行的，通过这样的模型将系统进行分解并单独进行性能评估。通过这种方法来做性能估计我是第一次见到，先向老院子学习一下。然而，这种估算的准确度有多少？这个值得进一步关注。
在响应时间的评估上，根据这个模型获得的各子系统的消耗时间（理论数据）作为度量依据，进一步关注各子系统的响应时间情况。在这里我们知道了SS2的压力最大响应时间最长，也是容易出现性能短板的地方，是系统优化的重点对象。另一方面，响应时间由数据库操作和业务处理时间组成，两者时间消耗达6：1，在一个业务流程中多次的数据库操作占了48/54=85%的时间比例，因此数据库查询优化也是一大重点。
关于吞吐量上，吞吐量与响应时间成反比没错，我觉得不应该是：吞吐量=并发量/响应时间，这个比例关系会随着并发用户数的增加而改变，同时这个并发用户数应该是服务器同时处理的用户数（业务数），而不是测试工具加压的并发数，这个也不好度量。
在吞吐量的估算上，存在这样的关系。（我也是刚总结出来的，不对的请指正，^_^）。吞吐量（TPS）*工作时间*并发用户数=总业务量
从系统级的吞吐量来说，根据“100个并发用户，响应时间不超过1.2S，每日处理80W条左右的业务，系统每日运行时间8小时”的需求来说：
当用户数为1时，TPS=80w/8/3600=27.7 业务/秒
当用户数为100时，TPS=27.7/100=0.277 业务/秒
因此只要能达到这个处理速度，并且响应时间不超过1.2S即可。
最后，集群中单机的损耗系数估计也会随着数量的不同的变化，估计在某个范围，如果变化程度太大则可参考程度降低。这个我也很想知道答案。
在这个讨论中我想到了很多以前没考虑过的问题，特别是Jackei的短板效应、老院子的数学模型都有新的体会，谢谢了！
根据老院子提供的线索来到这里，博主和老院子的讨论可能是很多设计者需要了解的。提一些个人的看法：
1，老院子提到的问题实际上是可以脱离测试的一个性能分解问题；
2，性能测试可以分为两种类型来进行：一种是在集成后、系统测试中进行，另一种是在集成前的子系统性能测试；
3，Jackei提到的联调，与老院子说的性能测试，分别是上述两种测试，所根据的性能指标来源也不同，前者是产品需求，后者是软件需求；
4，老院子需要的是根据产品需求分解后得到的各子系统软件需求中的非功能性需求，这一部分只能通过模型从产品需求计算得到；
5，分解过程的计算实际上是一个线性规划问题，约束条件为：
a) 串行各个子系统实际响应时间之和（并行过程取各并行最大值） < 产品需求要求的响应时间，即 1 / TPS
b) 对于各个子系统：实际响应时间 = 响应时间指标值（测试需要满足的值）+ 等待时间
c) 等待时间 = 上游空闲时间 + 下游子系统的进入时间
其中：
I，前一部分是由于上游子系统忙而造成的本子系统等待均摊到各个session的损耗，可以这样估算：响应时间指标值*平均空闲session数/并发session数
II，后一部分是由于下游session满而造成的等待时间，可以这样估算：响应时间指标值*平均等待session数/并发session数
最优情况下，是等待时间=0，则对于所有串行过程中的子系统，下值相同：session数/响应时间指标值。
6，上述模型有非常复杂的计算过程，工程中为简化起见，一般的做法是：先根据经验值先估算各个子系统的时间消耗比例——即老院子提到的根据数据库操作、文件操作各多少次，两者时间消耗达6：1等信息，折算成子系统时间消耗比例，尽可能满足（session数/响应时间指标值）为常量，则分解值的计算就是简单的多项式方程，很容易得到了。
Jackei,好期待您能继续写完,为我们这些新手提供更丰富的测试快餐！期待……谢谢！
@的的的
@FLJS
这部分写作以及相关工作的确是hold住好久了，下半年努力争取继续写吧 ：）