常見性能工具一覽

前言

測試工具

開源工具

商業工具

小結

前言

測試工具

開源工具

商業工具

小結

監控工具

Linux

tomcat

mysql

redis

nginx

小結

代碼級剖析工具

JAVA 方向

C/C++ 方向

其他

Linux 內核調試工具

六、前端工具

charlesproxy

httpwatch

safari 開發者工具

chrome 開發者工具

firefox 開發者工具

小結

前言

今天寫了一個調試工具的文章，就有人說起工具到底要會哪些。既然提到這兒了，那就多寫幾句吧。

測試工具

只說幾個典型的。

開源工具

Jmeter：這個工具現在應該是互聯網壓力測試的最常用工具了。用的人多，基本上取代了 loadrunner 的地位。apache 的項目都是牛B項目，不得不贊。現在說是做性能測試的，這個工具不會用，那是沒要被鄙視的。由于它也是需要一些開發功底，所以比較符合現在要求測試開發的潮流。但是在一些不差錢的企業中，畢竟開源工具得不到支持。老板們想找個替死鬼也找不到，所以在用外包做性能測試的領域中的市場占有率還有待提高。

現在云測試也都吹得風風火火，基本上也是各種的封裝。自己寫一套多麻煩。直接搭上一套，再寫幾個界面封裝下，現在出去也能一個場景賣上幾千塊錢了。所以在線的云測試工具中以它為基礎的還是不少。

Grinder：我看這個工具最新的更新日期是 2012 年。這個工具其實在 Jmeter 出現之前，可惜的是沒趕上好時候，我記得老早以前就看過這個工具的開發團隊出現分歧，導致工具發展緩慢。在一些早期的互聯網人里面，還有對它進行改造并形成自己的測試平臺的。國內某大互聯網廠商就是如此。這個工具和 Jmeter 的重合度比較高，所以對初學者，我不建議同時學 Jmeter 和Grinder。

也有以它為基礎改編成云測試版本的。

商業工具

LoadRunner：這個工具不得不說，在哥剛做性能測試的時候，這工具簡直是獨步天下的。那市場占有率，在售前的 PPT 里，有寫 85 %的，還有寫 95 %的。自豪得連自己會不會都不知道了。在 Mercury 時代的時候，確實一切都良好。市場穩步往上升。但是風高天黑的 2006 年 7 月 26 日惠普以 45 億美元收購了 Mercury 公司之后，就越來越笨重。直從 600 多M升級到 4 G左右。并且 HP 的市場做得出其不意的爛。之前一個筆記本裝上之后，還能跑得歡快。后來想運行起來就不堪重負了。一個好好的工具，因為時代的原因，再加上 HP 的市場做得如此之爛，最后也不得不慢慢被開源工具占具市場。一個工具賣幾十萬、上百萬。在國內這樣的商業環境下，你這定價就是在考驗自己的存活時長呀。除了一些要拿商業工具做替罪羊的企業買 100、200 的l icense 放在那里生銹、然后接著用 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 等之類的也是類似的特性。

小結

再次強調，不要糾結于工具，只要選擇適合的就好。關鍵是看好自己想實現的目的。從最低的成本和最長久的發展來考慮，選擇自己需要的。

性能測試工具永遠不會告訴你瓶頸在哪兒，它只能告訴你，有瓶頸了。

監控工具

對于監控工具，可以說是五花八門。

我經常會說，監控工具的選擇思路是：先全局監控，后定向定量監控。

大概說一下監控工具，基本上收費的，我都盡量不提。以免有打廣告的嫌疑。

對于現在用到的主流環境：linux/tomcat/mysql/nginx/redis 這一套東西。如果有人問到其他的，也可以在評論中說出來。

Linux

基本上對于性能分析工程師來說，如果是單機的話，命令就已經足夠。uptime/top/vmstat/mpstat/pidstat/dstat/nethogs/iostat/sar…多的列不完。如果說想保存歷史數據的話，建議用 prometheus 之類的工具，像這樣的工具有很多種，像 casti/ Nagios 也是比較不錯的。現在很多企業都基于開源的工具做了自己的監控平臺，從思路上來說大同小異。還有些比較強的團隊完全開發自己的監控平臺。其實這個代價已經不像以前那么高了，畢竟有開源的可以做參考；要改造也有明確的方向。

tomcat

除了自己的 manager 頁面，probe 也是個不錯的選擇。當然對多個節點也是可以用上面提到的 prometheus 系列的監控工具。

mysql

我基本上不用復雜的工具監控 mysql。如果節點不多，我覺得直接寫 SQL 也基本上夠用。show status+slowlog 之類的。另外，mysql 有 information schema 和 performance schema，基本上像 oracle 里的各種$視圖了。有一些工具中也帶監控功能，像 mysqlworkbench。

redis

除了 info 之外，還有些 GUI 的監控工具，commands/misses 之類的都能看到（因為我服務器上沒裝，就不截圖了，網上找圖不像話）。當然剛才提到的 prometheus 也可以做到。

nginx

其實沒幾個參數可以監控的。但是它的日志很有用。建議有條件的一定要裝個日志分析工具，實時或半實時地分析下nginx的日志。在配置中，也有 $request_time 和 $upstream_response_time 兩個參數可以用（個人推薦用前者）。

小結

如果想有報警的機制，就得用監控平臺像 prometheus 這樣的來配置了。如果是做運維的，這是必須的。

其實監控工具呢，可以給出的是數據是什么樣的。對于性能分析工程師來說，不管是用商業的還是開源的還是黑市淘來的監控工具，最重要的是要知道那些值的大小各有什么區別，并且要理清數據之間的關聯關系。這才是重點。

代碼級剖析工具

不管怎么吹，代碼級剖析工具對性能本身的損耗都是存在的。

并且損耗還不小。即使是在偏底層做，也照樣有很大的損耗。20-30% 損耗都是正常的。

要找好代碼級工具的切入點，一開始就用肯定是不理智。只要分析到了某一個具體的進程或線程，或者已經有了可疑代碼的具體方法，再上代碼級剖析工具就更有目的性了。

JAVA 方向

對 JAVA 來說，代碼級的剖析工具有好多。自帶的就有不少，像現在 SUN JDK 中的 jvirtualVM 就可以實時看 CPU 和內存在一個方法和對象上的消耗。還有 jstack/jmap 等工具可輔助。如果不想實時看，做下 dump 也可以看內存的占用。但是要想看方法調用時間就比較費勁一點。不過現在有不少的商業工具，比如說 jprofiler，這工具直到現在還是我所見到的在 java 剖析中功能最全面的工具（它是商業的）。

不僅有樹結構，還有調用圖。

建議大家盡量找到可替代的適合的開源工具。

C/C++ 方向

在這個方向上，其實不止有專門的代碼級剖析工具，像 valgrind, google perftools。也有系統級的調試工具可以用。各種的 trace工具，像 perf/systemtap/oprofile 之類的也都可用，并且內核級工具損耗要小一些。在 solaris 上有 Dtrace，那本《性能之顛》的書里幾乎全是 Dtrace 工具的例子。 并且這些工具還能生成火焰圖、熱力圖之類的。

其他

在其他語言上也有相應的剖析工具可用。

像 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.unfold perl stackcollapse-perf.pl perf.unfold &> perf.folded perl flamegraph.pl perf.folded >perf.svg

通過 Brendan Gregg 的寫好的工具（stackcollapse-perf.pl ，flamegraph.pl），基本上可以滿足大部分的要求。有興趣和有能力的也可以自己寫一下。Cor-Paul Bezemer 也寫過一個差分火焰圖的工具 flamegraphdiff，一個頁面顯示三個屏，點函數名時，其他圖上也會高亮顯示。如下所示：

六、前端工具

先以我所有的知識，說明一下前端的展現過程。

大致過程如上，在實際的展示過程中，有些是可以并行的。比如 html、css下載。這就涉及到 http1.1 協議的下載局限和瀏覽器支持的并發數量了。

為了能讓人盡快看到頁面的內容，瀏覽器也不會等所有的都干完了再展示，而是逐漸展示。

有的人可能看到頁面是一次展示出來的，那就是前端設計的太差了。

另外，不同的瀏覽器用的內核不一樣，所以展示的過程會有細微的差別。

還是回到工具上。

charlesproxy

上圖展示了一個請求的時間樹，可以在性能分析中判斷出哪個元素是比較耗時的。

flow 視圖展示時間。

這個工具要說好呢，也還是不錯的，但是要收費，如果和開源的其他工具一比較，這個收費就感覺不值了。

httpwatch

經典的視圖，看著就覺得舒服。這個瀑布視圖是我覺得前端性能分析工具中做的最好看的。

各元素的響應時間一目了然。并且也把時間細分的非常好。

但可惜的是它只能支持 windows，ipad，iphone。不知道這個工具開發者是怎么想的。

并且這個工具的專業版也收費。

safari 開發者工具

如果是喜歡簡潔的人，這個工具必然是首選。一如既往的 mac 風格（想想蘋果把 mac 團隊拆到 iphone 就很擔心以后的 mac 電腦的 os 升級都有可能慢很多呀）。

并且，把幾段時間給拆分開在上面也看的很清楚，網絡、js、內存、圖層渲染。

又免費功能也不少。

chrome 開發者工具

不僅有 safari 中的分層展示，還有倒著的火焰圖，你說說，真是啥都給你想到了，只需要你睜眼看它就行。

它的網絡部分，也是可以明確看到哪個地方浪費了時間的。

又免費又好用。

firefox 開發者工具

js調用關系圖。

網絡的瀑布視圖也不錯，細分也有，dns解析、SSL、發送、接收、緩沖之類的，要啥有啥。

js火焰圖也是有的，并且還挺炫麗。

性能視圖的樹視圖，只要看一眼就知道哪慢。

性能的瀑布分的非常細，以致于想看整體還要翻挺長。

小結

以上的工具中，都有對前端做調試的功能，下個斷點，改個頁面參數，復制請求，重發請求，自組裝請求之類的。

總之，對于前端的性能分析來說，工具真的已經做的非常完整清晰了。要是說分析時間消耗，看這些就夠了。

云性能測試服務 CPTS 應用性能管理 APM 應用性能調優

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。