Sitemesh のパフォーマンステストの結果は驚くべきものでした

最近、プロジェクト内のビューレイヤーのデコレータとしてサイトメッシュを使用したいと思い、今日サイトメッシュのパフォーマンステストを行いました。
ビュー層のパフォーマンスをテストしているだけであるため、システムフレームワークには Spring mvc3(3.0.3)+freemarker(2.3.16)+sitemesh(2.4.2) サーブレットコンテナー:jetty-6.1.21 jdk:1.6 のみが含まれてい
ます
。 0_17-b04
圧力テストツール:loadRunner 8.1
アプリケーションサーバー構成: 8cup Intel(R) Xeon(R) CPU E5410 @ 2.33GHz、メモリ: 4G

テストコード:

Javaコード

@Controller  
public class TestController {  
    @RequestMapping(value="/hello", method=RequestMethod.GET)  
    public void sayHello(Model model){  
        model.addAttribute("timestamp",new Long(System.currentTimeMillis()));  
    }  
}

フリーメーカーコード

<html>  
<head>  
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />  
    <meta http-equiv="Cache-Control" content="no-store"/>  
    <meta http-equiv="Pragma" content="no-cache"/>  
    <meta http-equiv="Expires" content="0"/>  
</head>  
    <title>freemarker title</title>  
<body>  
<#list 1..100 as r>  
<#list 1..1000 as xx>  
<h5>${timestamp%xx}</h5>  
</#list>  
</#list>  
</body>  
</html>

サイトメッシュ関連の設定:

web.xml:  
    <filter>  
        <filter-name>sitemesh</filter-name>  
        <filter-class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>  
    </filter>  
      
    <filter-mapping>  
        <filter-name>sitemesh</filter-name>  
        <url-pattern>/*</url-pattern>  
    </filter-mapping>  
  
decorators.xml  
<decorators defaultdir="/decorators">  
    <!-- Any urls that are excluded will never be decorated by Sitemesh -->  
    <excludes>  
        <pattern>/exclude.jsp</pattern>  
        <pattern>/exclude/*</pattern>  
    </excludes>  
  
    <decorator name="main" page="main.jsp">  
        <pattern>/*</pattern>  
    </decorator>  
</decorators>

デコレータページ main.jsp:

<%@ page language="java" contentType="text/html; charset=UTF-8"  
    pageEncoding="UTF-8"%>  
<%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator" prefix="decorator" %>  
<%@ taglib uri="http://www.opensymphony.com/sitemesh/page" prefix="page" %>  
  
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">  
<html>  
<head>  
    <title><decorator:title default="Mysterious page..." /></title>  
    <decorator:head />  
</head>  
<body>  
<h1>header</h1>  
             <decorator:body />  
<h1>footer</h1>  
</body>  
</html>

30 人のユーザーが上記のページに同時にアクセスし、
JVM 最適化パラメータを使用せずに Jetty を起動し、サイトメッシュを使用しない場合のテスト結果

Visualvm 監視のスクリーンショット

サイトメッシュ使用時のテスト結果

Visualvm 監視のスクリーンショット

上記のテスト結果から、ページの平均応答時間に対するサイトメッシュの影響は比較的小さいことがわかり、この影響は基本的に許容範囲内であると思います。
しかし、Visualvm の監視結果を見て非常に驚いたのは、sitemesh を使用した後、jvm のメモリ使用量が使用しない前の 10 倍に急増し、同時に CPU の使用率も 3-オリジナルの 4 倍使用量の急激な増加により、jvm の GC の頻度が大幅に増加しました。

新しいラウンドのテストは、参考までに、 rapid-framework の継承実装によって得られたテスト結果を参照してください。

外国人が実装したフリーマーカーレイアウト http://richardbarabe.wordpress.com/2009/03/19/freemark-a-brief-example/ から得られたテスト結果を参照してください。

上記の一連のテストから、これら 2 つのソリューションの実装効果は、ページ応答時間の点ではほぼ同じであり、基本的に違いはないことがわかります。メモリの変動はほぼ同じですが、唯一の大きな違いは、ラピッドテストを使用するシーンでは CPU 使用率の変動が大きいのに対し、マクロを使用して実装されたデコレータでは CPU 使用率の変動が少なく、CPU 使用率が比較的低いことです。
なお、Rapidを使用したシーンのスレッド数の変動グラフは他のシーンに比べて一目瞭然ですが、テスト中はこの状況に気付かなかったので、スレッド数が増加した理由はわかりません。スレッド数はまだです。このシナリオでは、リクエストの処理が若干遅いため、VVM によってカウントされるアクティブなスレッドの数が他のシナリオよりも多くなっているのではないかと考えられます。
上記のテスト結果が参考になれば幸いです。

元の URL: http://seanhe.iteye.com/blog/715100

Sitemesh のパフォーマンス テストの結果は驚くべきものでした

おすすめ

Sitemesh のパフォーマンステストの結果は驚くべきものでした