jmeter性能分析

我的上一篇文章描述了如何使用JMeter完成異步REST / HTTP服務(wù)的壓力測(cè)試或負(fù)載測(cè)試。 但是，運(yùn)行這樣的測(cè)試通常表明被測(cè)系統(tǒng)不能很好地應(yīng)對(duì)增加的負(fù)載。 現(xiàn)在的問(wèn)題是如何找到瓶頸？

深入研究代碼以檢測(cè)可疑部分可能是一種替代方法。 但是考慮到潛在的巨大代碼庫(kù)，因此考慮到瓶頸隱藏¹的眾多可能性，這看起來(lái)似乎不太有希望。 幸運(yùn)的是，有一些工具可以在遙測(cè)²的基礎(chǔ)上提供有效的分析功能。 記錄和檢查此類測(cè)量值通常稱為概要分析，而本博文則介紹了如何使用Yourkit ³進(jìn)行此操作。

首先，我們推出我們的SUT（ 變體系ü的nDer 牛逼 EST），并使用JMeter的建立系統(tǒng)的負(fù)荷。 為此，JMeter可能執(zhí)行一個(gè)測(cè)試方案，該方案模擬了多個(gè)用戶向SUT發(fā)送大量請(qǐng)求的情況。 在測(cè)試場(chǎng)景中定義的測(cè)試計(jì)劃 。 后者可能包含偵聽(tīng)器 ，這些偵聽(tīng)器允許捕獲請(qǐng)求的執(zhí)行時(shí)間并提供統(tǒng)計(jì)信息，例如最大/最小/可用性請(qǐng)求持續(xù)時(shí)間，偏差，吞吐量等。 這就是我們檢測(cè)到系統(tǒng)擴(kuò)展性不佳的方式…

在發(fā)現(xiàn)之后，我們使Yourkit可以檢索遙測(cè)。 因此，SUT的VM由特殊的探查器代理啟動(dòng)。 探查器工具提供了多個(gè)視圖，這些視圖允許實(shí)時(shí)檢查CPU利用率，內(nèi)存消耗等。 但是，要全面分析例如SUT在負(fù)載下的性能，Yourkit需要通過(guò)所謂的快照捕獲代理提供的CPU信息。

建議在單獨(dú)的計(jì)算機(jī)上運(yùn)行SUT，JMeter和Yourkit，以避免篡改測(cè)試結(jié)果。 在同一臺(tái)機(jī)器上運(yùn)行例如SUT和JMeter可能會(huì)降低吞吐量，因?yàn)镴Meter線程可能會(huì)消耗大量可用的計(jì)算時(shí)間。

考慮到此設(shè)置，我們將介紹一個(gè)概要分析會(huì)話的小示例。 以下代碼段是我們用作SUT的基于JAX-RS的服務(wù)⁴的摘錄。

@Path( '/resources/{id}' ) public class ExampleResourceProvider {private List<ExampleResource> resources;[...]@Override@GET@Produces( MediaType.TEXT_PLAIN )public String getContent( @PathParam( 'id' ) String id ) {ExampleResource found = NOT_FOUND;for( ExampleResource resource : resources ) {if( resource.getId().equals( id ) ) {found = resource;}}return found.getMessage();}

該服務(wù)在ExampleResource實(shí)例列表中執(zhí)行查找。 ExampleResource對(duì)象只是將標(biāo)識(shí)符映射到以String表示的消息。 找到給定標(biāo)識(shí)符的消息將返回。 在使用GET請(qǐng)求調(diào)用服務(wù)時(shí)，您可以使用瀏覽器測(cè)試結(jié)果：

出于演示目的，服務(wù)的粘合代碼以無(wú)序方式初始化了500000個(gè)元素的列表。

一旦運(yùn)行了SUT，就可以使用JMeter在負(fù)載下設(shè)置它。 該測(cè)試計(jì)劃一次執(zhí)行大約100個(gè)并發(fā)請(qǐng)求。 如下圖所示，平均請(qǐng)求執(zhí)行時(shí)間約為1秒。

Yourkit在JMeter測(cè)試計(jì)劃執(zhí)行期間記錄的CPU遙測(cè)揭示了請(qǐng)求執(zhí)行時(shí)間長(zhǎng)的原因。 選擇配置文件快照的“ Hot spots選項(xiàng)卡，將顯示列表迭代消耗了約72％的CPU利用率。 查看列出了所選熱點(diǎn)方法的調(diào)用者樹(shù)的Back Traces視圖，我們發(fā)現(xiàn)示例服務(wù)方法導(dǎo)致列表迭代。

因此，我們?cè)谙乱徊街懈姆?wù)實(shí)現(xiàn)，以對(duì)有序列表使用二進(jìn)制搜索進(jìn)行ExampleResource查找。

@Override@GET@Produces( MediaType.TEXT_PLAIN )public String getContent( @PathParam( 'id' ) String id ) {ExampleResource key = new ExampleResource( id, null );int position = Collections.binarySearch( resources, key );return resources.get( position ).getMessage();}

之后，我們重新運(yùn)行JMeter測(cè)試計(jì)劃：

現(xiàn)在平均請(qǐng)求大約需要3毫秒，這是一個(gè)很大的改進(jìn)。

查看相應(yīng)的CPU性能分析會(huì)話的Hot spots ，可以確認(rèn)由我們的方法引起的瓶頸已經(jīng)消失。

誠(chéng)然，以上示例中的問(wèn)題似乎非常明顯。 但是我們?cè)谏a(chǎn)代碼中發(fā)現(xiàn)了一個(gè)非常相似的代碼，它隱藏在系統(tǒng)的深度中（可惜……）。 重要的是要注意，在開(kāi)始?jí)毫拓?fù)載測(cè)試之前，問(wèn)題并沒(méi)有變得很明顯⁵ 。

我想我們?cè)谡业皆蛑?#xff08;如果有的話）將花費(fèi)大量時(shí)間手動(dòng)檢查代碼庫(kù)。 然而，剖析會(huì)議直接將我們指向所有邪惡的根源。 通常情況下，實(shí)際問(wèn)題并不難解決。 因此，概要分析可以幫助您更有效地處理一些工作。

至少它對(duì)我有用-順便說(shuō)一下-這也很有趣

請(qǐng)注意，導(dǎo)致瓶頸的代碼也可能屬于第三個(gè)庫(kù)。 ?

當(dāng)我現(xiàn)在在一個(gè)客戶項(xiàng)目中進(jìn)行這種分析時(shí)，我想到了寫(xiě)這篇文章的想法?

我在這里沒(méi)有做任何工具廣告或評(píng)級(jí)-我只是使用我熟悉的工具來(lái)提供一個(gè)更抽象的概念的可復(fù)制示例。 市場(chǎng)上有很多更好的工具可以滿足您的需求?

請(qǐng)注意，本文中的代碼片段的唯一目的是作為如何查找和解決性能瓶頸的示例。 片段編寫(xiě)得很差，不應(yīng)以任何方式重復(fù)使用！ ?

根據(jù)我的經(jīng)驗(yàn)，新創(chuàng)建的代碼庫(kù)包含其中的一些塊是很常見(jiàn)的。 因此，有這樣的測(cè)試是必須的，以便找到性能問(wèn)題的顧客發(fā)現(xiàn)他們?cè)谏a(chǎn)之前... ?

參考：我們的JCG合作伙伴 Frank Appel在Code Affine博客上通過(guò)JMeter和Yourkit對(duì)REST / HTTP服務(wù)進(jìn)行了性能分析 。

翻譯自: https://www.javacodegeeks.com/2012/11/performance-analysis-of-resthttp-services-with-jmeter-and-yourkit.html

jmeter性能分析

總結(jié)

以上是生活随笔為你收集整理的jmeter性能分析_使用JMeter和Yourkit进行REST / HTTP服务的性能分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。