Sitemesh performance test results are amazing

Recently, I wanted to use sitemesh as a decorator for the view layer in a project, so I did a sitemesh performance test today.
Since it is only testing the performance of the view layer, the system framework only has spring mvc3(3.0.3)+freemarker(2.3.16)+sitemesh(2.4.2)
servlet container: jetty-6.1.21
jdk:1.6.0_17-b04
pressure Test tool: loadRunner 8.1
application server configuration: 8cup Intel(R) Xeon(R) CPU E5410 @ 2.33GHz; memory: 4G

Test code:

java code

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

freemaker code

<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>

sitemesh related configuration:

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>

Decorator page 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 users visit the above page concurrently,
the test results when jetty starts without using any jvm optimization parameters and does not use sitemesh

Visualvm monitoring screenshot

Test results when using sitemesh

Visualvm monitoring screenshot

From the above test results, it can be seen that the impact of sitemesh on the average response time of the page is relatively small, and I think this impact is basically acceptable.
But from the monitoring results of Visualvm, I was very surprised. After using sitemesh, the memory usage of jvm increased sharply, which was 10 times that before it was not used. At the same time, the usage rate of cpu was also 3-4 times the original. The sharp increase in usage has caused jvm's GC to be much more frequent.

A new round of tests, for your reference, refer to the test results obtained by the inheritance implementation of rapid-framework

Refer to the test results obtained from the freemarker layout http://richardbarabe.wordpress.com/2009/03/19/freemarker-a-brief-example/ implemented by foreigners

From the above round of tests, it can be seen that the implementation effects of these two solutions are almost the same in terms of page response time, and there is basically no difference. The memory fluctuations are roughly the same. The only big difference is that the CPU usage fluctuates more frequently in the scene using the rapid test, while the decorator implemented using macros has less fluctuations in CPU usage, and the CPU usage is relatively low.
In addition, the fluctuation graph of the number of threads in the scene using rapid is more obvious than that of other scenes, but I didn't notice this situation during the test, so I don't know the reason for the increase in the number of threads yet. I suspect that in this scenario, due to the slightly slower request processing, the number of active threads counted by VVM is higher than in other scenarios.
I hope the above test results are of reference value to you.

Original URL: http://seanhe.iteye.com/blog/715100

Sitemesh performance test results are amazing

Guess you like