loadrunner破解版下载(loadrunner2021安装)

一、前言

今天写了一篇关于调试工具的文章，有人谈到工具应该是什么。既然你提到了，那我们就多写几句吧。

二、测试工具

就几个典型的。

1、开源工具Jmeter：这个工具现在应该是互联网压力测试的最常用工具了。用的人多，基本上取代了 loadrunner 的地位。apache 的项目都是牛B项目，不得不赞。现在说是做性能测试的，这个工具不会用，那是没要被鄙视的。由于它也是需要一些开发功底，所以比较符合现在要求测试开发的潮流。但是在一些不差钱的企业中，毕竟开源工具得不到支持。老板们想找个替死鬼也找不到，所以在用外包做性能测试的领域中的市场占有率还有待提高。 现在云测试也都吹得风风火火，基本上也是各种的封装。自己写一套多麻烦。直接搭上一套，再写几个界面封装下，现在出去也能一个场景卖上几千块钱了。所以在线的云测试工具中以它为基础的还是不少。Grinder：我看这个工具最新的更新日期是 2012 年。这个工具其实在 Jmeter 出现之前，可惜的是没赶上好时候，我记得老早以前就看过这个工具的开发团队出现分歧，导致工具发展缓慢。在一些早期的互联网人里面，还有对它进行改造并形成自己的测试平台的。国内某大互联网厂商就是如此。这个工具和 Jmeter 的重合度比较高，所以对初学者，我不建议同时学 Jmeter 和Grinder。 也有以它为基础改编成云测试版本的。2、商业工具LoadRunner：这个工具不得不说，在哥刚做性能测试的时候，这工具简直是独步天下的。那市场占有率，在售前的 PPT 里，有写 85 %的，还有写 95 %的。自豪得连自己会不会都不知道了。在 Mercury 时代的时候，确实一切都良好。市场稳步往上升。但是风高天黑的 2006 年 7 月 26 日惠普以 45 亿美元收购了 Mercury 公司之后，就越来越笨重。直从 600 多M升级到 4 G左右。并且 HP 的市场做得出其不意的烂。之前一个笔记本装上之后，还能跑得欢快。后来想运行起来就不堪重负了。一个好好的工具，因为时代的原因，再加上 HP 的市场做得如此之烂，最后也不得不慢慢被开源工具占据市场。一个工具卖几十万、上百万。在国内这样的商业环境下，你这定价就是在考验自己的存活时长呀。除了一些要拿商业工具做替罪羊的企业买 100、200 的 license 放在那里生锈、然后接着用 65536 全协议的盗版之外，似乎现在已经没有什么出路了。SilkPerformer: 不得不说，这个工具现在还存活着完全和中国市场没有关系。在 borland 也是在 2006 年以 1 亿买了 segua 公司，之后在国内市场上就是半死不活的样子。后来 2009 年 Micro Focus 宣布以 7500 万美元收购 Borland。这个老牌的软件企业，在欧美还是比较吃得开。可是在国内，从压力工具的市场上来说，就那几个不温不火在外企里养老的销售也干不出什么特色来。以上商业工具的底层实现是从 socket 层抓起，所以从实现上来说，这是绝对的优势。前面提到的开源工具基本上是从应用层抓起，所以在 init 部分会稍微慢一些。不过一个 4 G的工具和一个 100 多M的工具比起来，是不是想想就觉得 4 G用起来好累了？ 基于现在云架构的应用，这些商业工具基本上没有什么优势。其实从大的实现的架构上来说，这些工具可是说是没什么区别。看好，我说的是实现的架构，不是实现的内部逻辑。都是控制器、负载机、分布式、多线程、共享资源池之类的思路。 所以压力工具要学习，就学 Jmeter 和 LoadRunner 就好了，据我所知，现在一些知名的互联网企业中，仍然有用 LoadRunner破解版的。65535 vusers 呀，估计 Jmeter 要是实现这么多，自己都撑不住了。另外，还有些工具像：QAload/webload/openSTA/httpperf/loadUI/ab/siege 等之类的也是类似的特性。3、小结

还是那句话，不要纠结工具，选对就好。关键是要对自己想要达到的目标保持乐观。考虑成本最低，开发时间最长，选择自己需要的。

性能测试工具永远不会告诉你瓶颈在哪里，它只能告诉你存在瓶颈。

三、监控工具

有各种各样的监控工具。

我常说的监测工具选择是:先全局监测，再定向定量监测。

先说监控工具。基本收费的东西我尽量不提。以免有广告嫌疑。

针对目前主流环境:linux/tomcat/mysql/nginx/redis。如果有人问别的，也可以在评论里说。

1、Linux

基本上对于性能分析工程师来说，如果是单机，命令就够了。uptime/top/vmstat/mpstat/pidstat/dstat/net hogs/iostat/sar……如果要保存历史数据，建议使用prometheus等工具。像这样的工具有很多种，casti/ Nagios也挺好的。现在很多企业都基于开源工具做了自己的监控平台，思路都差不多。有些强队已经完全开发了自己的监控平台。其实这个价格没有以前高了。毕竟有开源的可以参考；转型也要有明确的方向。

2、tomcat

除了自己的经理页面，probe也是一个不错的选择。当然，上面提到的prometheus系列监控工具也可以用于多个节点。

3、mysql

我基本不使用复杂的工具来监控mysql。如果节点不多，我觉得直接写SQL基本就够了。显示状态+slowlog之类的。此外，mysql还有信息模式和性能模式，基本上就像oracle中的各种$视图。有一些工具带有监控功能，比如mysqlworkbench。

4、redis

除了info，还有一些GUI监控工具，比如commands/miss，可以看到(因为我的服务器上没有安装，就不截图了，网上找图太离谱了)。当然，刚才提到的普罗米修斯也可以做到。

5、nginx

实际上，可以监控的参数很少。但是它的日志非常有用。建议您必须安装日志分析工具，实时或半实时分析nginx日志。在配置中，也有两个参数:upstream_response_time和upstream _ response _ time(我个人推荐前者)。

6、小结

想要有报警机制，就得用普罗米修斯这样的监控平台来配置。如果是为了运维，那是必须的。

其实监控工具呢？能给出的是数据是什么样的。对于性能分析工程师来说，无论是使用商业或开源的监控工具，还是黑市的监控工具，最重要的是要知道数值和大小的区别，以及整理数据之间的相关性。这才是重点。

四、代码级剖析工具

无论你怎么吹，代码级的剖析工具都会有性能损失。

而且损失还不小。即使做到了下层，还是有很大的损失。20-30%的亏损是正常的。

要找到代码级工具的突破点，一开始就用肯定是不理智的。只要分析一个特定的进程或者线程，或者有可疑代码的特定方法，去代码级的分析工具就更有目的性了。

1、J *** A 方向

对于J *** A，有很多代码级的解析工具。有很多人跟他们一起来。例如，SUN JDK中的jvirtualVM可以实时观察方法和对象中CPU和内存的消耗。还有jstack/jmap等工具辅助。如果不想实时看，也可以通过做dump来看内存使用情况。但是，查看方法调用时间有点困难。但是也有很多商业工具，比如jprofiler，它仍然是我见过的java解析中最全面的工具(它是商业的)。

不仅有树形结构，还有调用图。

建议我们尝试寻找替代的合适的开源工具。

2.C/C++方向

在这个方向上，实际上有不止一个专门的代码级剖析工具，比如valgrind，google perftools。也有系统级调试工具可用。perf/systemtap/oprofile等各种跟踪工具也有，内核级工具损耗更小。solaris上有Dtrace，性能之巅这本书几乎全是Dtrace工具的例子。而且这些工具还可以生成火焰图，热图之类的。

3、其他

其他语言中也有相应的分析工具。

像 PHP 有 Xdebug、xhprof；python 有cprofile、memoryprofiler、lineprofiler；.net有CLR profiler；Go语言有pprof（这个是移植过来的，google perf 中的工具更多）。

不管是什么语言，几乎都有类似的工具存在。有了这些工具和系统级调试工具，发现代码级性能问题只是几分钟的事情。

五、Linux 内核调试工具

在这里，我也提一下工具的使用。以perf为例。如果你对其他工具感兴趣，也可以探索一下，比如systemstap。GDB近期不打算修复它。毕竟年纪有点大了，感觉不像是在追风。

Perf是大多数linux自带的工具。有些前提条件就不说了，就是编译内核的时候，你要选择一些东西，这些都是琐碎的。遇到这样的问题，我一般会丢给另一个兄弟去处理。哈哈。

以CPU消耗为例。这里最好带-g参数，这样可以看到如下的调用关系。这里可以看到有[k]或者[。]中，其中[k]表示内核状态；[.]表示用户状态。看你想看的。

如果在这里跟踪自己的应用，可以根据函数名直接找到。

并且可以生成火焰图，如下图所示，可以分三步生成。

perf script -i perf.data &> perf.unfoldperl stackcollapse-perf.pl perf.unfold &> perf.foldedperl flamegraph.pl perf.folded >perf.svg

性能脚本-i性能数据& >perf . unfoldperl stack collapse-perf . pl perf . unfold & >perf . folded perl flame graph . pl perf . folded & gt；性能. svg

用Brendan Gregg写的工具(stackcollapse-perf.pl，flamegraph.pl)基本可以满足大部分需求。有兴趣有能力的也可以自己写。Cor-Paul Bezemer还写了一个分裂火焰图的工具flamegraphdiff。一个页面显示三个屏幕，当点击函数名时，其他图将被突出显示。如下所示:

六、前端工具

先用我所有的知识，解释一下前端的呈现流程。

流程大致如上。在实际显示过程中，有些是可以并行的。比如html和css下载。这就涉及到http1.1协议的下载限制和浏览器支持的并发数量。

为了让人们尽快看到页面的内容，浏览器不会等一切都结束了再显示，而是逐步显示。

有的人可能看到页面显示一次，就是前端设计太差。

另外，不同的浏览器使用的内核不同，所以呈现的过程也会略有不同。

让我们回到工具上来。

1、charlesproxy

该图显示了一个请求时间树，它可以用来确定在性能分析中哪个元素是耗时的。

flow 视图展示时间。显示流程视图的时间。

这个工具是好的，现在还是好的，但是要收费。如果和其他开源工具相比，这个收费是不值得的。

2、httpwatch

经典的观点，看着很舒服。这个瀑布视图是我认为最好的前端性能分析工具。

每个元素的响应时间都很清楚。并且也很好的细分了时间。

但遗憾的是，它只能支持windows、ipad和iphone。不知道这个工具的开发者是怎么想的。

而且这个工具的专业版也是收费的。

3、safari 开发者工具

如果你喜欢简单，这个工具一定是首选。一如既往的mac风格(想到苹果把mac团队拆解到iphone，我担心以后mac电脑的os升级可能会慢很多)。

而且把网络、js、内存、图层渲染等几个时间段拆分也能看得很清楚。

还有很多免费的功能。

4、chrome 开发者工具

不仅有safari中的分层显示，还有倒置的火焰画面。告诉我，我真的为你想好了一切，睁开眼睛看看就好了。

在它的网络部分，你也可以清楚地看到你的时间浪费在了哪里。

免费且易于使用。

5、firefox 开发者工具

Js调用图。

网络的瀑布视图也不错，也有细分，比如dns解析，SSL，发送，接收，缓冲等等。

Js火焰图也有，还挺炫的。

性能的树形视图，一看就知道哪个慢。

表演的瀑布如此精细，看完整个还挺长的。

6、小结

以上工具都有调试前端的功能，比如下一个断点，改变页面参数，复制请求，重发请求，自组装请求等等。

总之，对于前端性能分析，工具真的已经做的很完整很清晰了。说到分析时间消耗，看看这些就够了。