当前位置:首页 > 林北杂谈 > 正文

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、小结

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

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

0