摘要：Apache + jk + Tomcat = cluster Monitoring and Managing Tomcat Clusters Using JMX Clustering and Load Balancing in Tomcat 5, Part 1 Clustering and Load Balancing in Tomcat 5, Part 2
阅读全文
posted @ 2006-06-21 22:11
随笔分类 - 04.软件性能测试
慢慢的开始比较多的关注性能测试了，整理的资料和写的东西也会多起来，所以单列一个目录。
摘要：原文出处：UML软件工程组织 1. Windows性能计数器分析 对象 计数器 分析 ...
阅读全文
posted @ 2006-06-16 11:56
摘要：也是一篇不错的文章，理清一些基本的思路。
英文版
中译版
阅读全文
posted @ 2006-04-13 12:34
摘要：Tuning Your Stress Test Harness
一篇不错的文章，讨论了一个在性能测试过程中很容易产生不同理解的概念——并发。另外，还提出了如何通过对服务器施加有效的负载来获得更加真实可靠的性能数据的方法。
很值得一读。
阅读全文
posted @ 2006-04-11 23:01
摘要：本来也想自己写这样一个系列的文章，不过后来想到 Bill 不太可能不预先给我们准备好这些东西，于是去 MSDN 搜索了一下，嗯，收获还不少。有兴趣的朋友可以参见这个链接。
随着各家厂商的竞争越来越激烈，技术支持和服务逐渐变成了竞争的主要内容，于是，就有了 M$ MSDN 、IBM developerWorks 这样的地方，可以有大量的资料让我们免费获取。大家鼓掌鼓励一下
阅读全文
posted @ 2006-04-04 09:42
摘要：去年整理的一篇文档，最近做性能测试，翻出来参考，自我感觉良好，同大家分享。 ^_^
阅读全文
posted @ 2006-03-24 09:32
摘要：今天在51的坛子上发现有测友提到 LoadRunner 的 License 被限制的问题。记得原来听朋友说，现在市面上流行的几个 LR 的 License 都不是盗版的，而是 Mercury 放出来的，虽然支持的并发用户数少，但是很多时候也足够用了。现在 Mercury 已经在性能测试工具方面占领了很大的市场，就把原来的 License 禁止了，有点“卸磨杀驴”的意思。
阅读全文
posted @ 2006-03-16 17:58
摘要：IPTV的未来发展正在成为业界的焦点话题。据市场研究公司MRG的统计，全球IPTV用户将由2004年的200万增加至2010年的2000万，预计全球IPTV市场2005～2010年的复合增长率为102%。 在国内，IPTV产业尚处于试验阶段，中国电信、中国网通、中国铁通正在积极开展IPTV试验。
目前已有很多设备厂家提供IPTV系统平台和设备，业界公认IPTV业务包含两种基本业务：VOD点播和TV直播。国内IPTV的发展如火如荼，对于 IPTV系统的测试也亟需进行规范，本文拟将对IPTV系统的这两种基本业务的性能测试进行简单的探讨。本文仅仅考虑端到端的性能测试，测试的观察点在于用户侧，不考虑服务器端的分级缓存性能。
由于VOD点播网络和TV直播网络在网络结构上的不同，VOD分发需要依靠CDN网络，而TV的分发则需要依靠组播网络，不需要CDN网络进行缓存，基于此，该两种业务性能测试的着重点也不尽相同。
阅读全文
posted @ 2006-02-16 16:27
摘要：在LR的参考资料中也可以看到，建议将登录系统这类的脚本放在Init部分，而将业务相关的脚本放到Action部分，退出系统的脚本放到End部分。这样做除了使脚本结构更加清晰以外，还可以保证在多次迭代时，不用反复的重复登录和退出操作。
今天看到论坛上有朋友问是否一定要每次录制完以后把脚本从Aciton部分分别剪切、粘贴到Init和End部分？其实可以在录制脚本的时候就分段录制的。如下图所示
阅读全文
posted @ 2005-09-01 21:45
摘要：将LR返回结果保存为Session的好处之一，是可以添加注释，将你在分析图表过程中的思路记录下来，不至于下次看时毫无头绪，重新来过。
阅读全文
posted @ 2005-08-31 22:37
摘要：在进行稳定性测试时，我们希望在可以充分利用时间和测试资源，让两个场景分别在前半夜和后半夜运行。为此需要准备两台Controller机，分别打开不同的场景，并对两个场景持续运行的时间进行设置——例如都运行6个小时。然后通过Scenario Start Time来分别设置两个脚本开始运行的时间——例如第一个脚本设置为从当天下午6点钟开始运行，第二个脚本从第二天凌晨1点钟开始运行。如下图
阅读全文
posted @ 2005-08-24 23:12
摘要：上面这个图是对Google的搜索功能的一次测试后，使用“Merge Graphs…”功能将Hits per Second、Throughput、Average Transaction Response Time三个图组合在一起生成的图表，我们希望从中可以看出在场景执行过程中，随着Hits per Second的增加，Throughput的变化情况，以及对Average Transaction Response Time的影响。
但是因为三个原图中的性能计数器的数值和单位都不同，当Analysis使用同样的比例进行显示时，根本无法体现出三者的关系——图中高高在上的绿色线是Throughput，而几乎平伏在接近0水平的是Hits per Second和Average Transaction Response Time。
这种情况下，除了手工调整各个性能计数器的显示比例外，一个更简单有效的方法是使用“View Measurement Trends”功能（如图1所示）。使用后的效果就像下面这样
阅读全文
posted @ 2005-08-23 23:28
摘要：我们需要对一个商业系统进行整体性能测试，按照对用户以往使用情况的分析，我们整理出了用户在多个业务上的分布情况，也在Controller中添加了这些业务所对应的脚本，设置了每个脚本对应的虚拟用户数。我们还希望可以模拟一开始就让所有用户同时在线的情况，但我们又不希望使用集合点在每次迭代时都对各个业务造成那么大的压力——因为对组合场景来说，这种压力似乎又不太合理……
阅读全文
posted @ 2005-08-22 20:07
摘要：有些时候我们需要将多个返回结果放在一起进行对比，例如，一个场景在多个不同的发布版本上运行后，我们希望通过对测试结果的比较来判断不同版本的性能差别；或者对同一个压力点，我们设计了几个场景，在这几个场景都运行通过后，我们要比较一下不同的负载对系统的影响。当然，你也可以因为更多的原因产生这种需求。不过不管怎么说，如果为了实现这个愿望，而不得不同时打开几个Analysis，那恐怕的确是有些麻烦——况且在比较这些结果时还要不停的切换窗口。
LoadRunner提供的一个比较好的功能可以帮助我们更简单的完成这项工作——“Cross with Result”。如下图所示
阅读全文
posted @ 2005-08-22 00:54
摘要：在一个使用LoadRunner进行的性能测试项目中，需要管理的东西通常有三种：
1. 通过VuGen生成的脚本；
2. 通过Controller生成的场景；
3. 执行场景生成的返回结果。
我通常习惯于用下面的目录结构来管理这些内容，如下图
阅读全文
posted @ 2005-08-21 12:21
摘要：每次在Controller中运行一个场景时，LR都会把返回结果保存在你指定的目录下，场景运行结束后，你可以在该目录中找到一个扩展名为“lrr”的文件，双击这个文件就可以在Analysis中看到在本次场景运行过程中LR收集到的各种信息。但是每次在Analysis中打开返回结果时，LR都要去ACCESS数据文件中读取数据，然后初始化图表，耗时太长。所以我们可以将返回结果保存成Session ……
阅读全文
posted @ 2005-08-20 16:11
摘要：
折腾了一阵，总算是在自己那台赛扬566/128M内存的机器上把LR装好了。顺便看了看LR的手册，嗯，这样的机器也还是可以跑起来的 ^_^ 等到年底家里再添台机器，就可以搭个小环境在家里作试验了 ^_^
阅读全文
折腾了一阵，总算是在自己那台赛扬566/128M内存的机器上把LR装好了。顺便看了看LR的手册，嗯，这样的机器也还是可以跑起来的 ^_^ 等到年底家里再添台机器，就可以搭个小环境在家里作试验了 ^_^
阅读全文
posted @ 2005-08-20 11:56
摘要：
明确了具体的性能要求后，可以开始进行测试，确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此，在测试中消除尽可能多的变数很重要。例如，代码中的错误可以导致出现性能问题，甚至掩盖性能问题。要精确地比较不同性能测试的结果，应用程序必须正确地工作。如果调整过程修改了组件的实现，则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外，硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。
阅读全文
posted @ 2005-05-19 11:47
摘要：Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！
然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？
阅读全文
posted @ 2005-05-10 15:23
摘要： 随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。
阅读全文
posted @ 2005-05-10 14:07
浙公网安备 33010602011771号