You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Michal Chmielewski <me...@liquid.net> on 2003/02/15 06:53:14 UTC
Performance
I think i may need some help regarding optimizing Velocity's performance since I had tried everything that I know how.
I've scanned the group and had found fantastic descriptions about Velocity's performance; somone mentioned being able to clear 1,000,000 templates in 1 hour (277 per second); somone else mentioned 1500 / second .... but currently i am observing something very different.
To begin with, I have been stressing our app that embeds Velocity 1.3.1-rc2. Run#1 was a steady load of 100 users (this is more or less your typical database application) viewing a page, filling a form, submitting, viewing another page, not a very complicated sequence. I was able to squeeze about 7 seconds per HTTP reqeust that required a Velocity template merge (so 100/7 = about 14req /sec, about 1,234,285/day). I had quickly realized that the DB was a bottleneck in Run#1 (so much so that 92% of the 7 seconds of the request was taking somehwere in the db layer). [ I am using wall clock, not CPU time. ]
So, for Run#2 I increased the number of db connection accessible to the application from 5 to 20. An unexpected result of this was that requests were taking *longer* (8-9 seconds) to complete and the bottleneck was *not* the database anymore but the Velocity Template merges (which happen at the end of the request, when context is ready and template is merged). Now, the 95% of the request time was spent doing the merges. It seems that since the db operations were completing much more quickly, more threads were spending time in the final stages of the requests simulaneusly (doing the merges).
I have done the obvious things that I can think off: (1) caching is on, (2) reloading is off (3) logger is NULL. The servlet's response writer is configured to buffer 128kb of data and when I run the stress and ping the server for a reply to a request i can see the reply starting after 8-9 seconds and coming down in one nice flush - this means to me that the buffer is big enough to hold the whole response nicely, so the network is not an issue during merges.
There is only 1 place for the file resource loader to look for templates and i can verify by timing that the very first request that results in a template fetch is longer then subsequent ones (by a factor of 10, which means that Velocity is caching the templates ok and not re-parsing them).
To further convince myself, i had put together this simple Velocity Template
<html>
<head>
<title>Template Merge Test</title>
<body>
#set($cnt = $event.getOptionalIntParameter("cnt"))
#if ($cnt < 0)
#set($cnt = 10)
#elseif ($cnt > 500)
#set($cnt = 500)
#end
<h2>Template Merge test</h2>
Number of loops set to: $cnt
<p>To change this, call this URI with query argument <b>cnt=number</b>,
where number is the number of loops you want the test to go through (max=500)
$formatter.makeAlternator("color","#dd7777","#77dd77","#7777dd")
<hr>
#foreach($z in [1..$cnt])
<h2> Table $z of $cnt </h2>
<table border=1 cellpadding=5 cellspacing=0>
#foreach ($x in [0..25])
<tr>
#foreach ($y in [0..10])
<td bgcolor=$color> ($x,$y) </td> $color.alternate()
#end
</tr>
#end
</table>
#end
</body>
</html>
and a comparable JSP page.
I had stressed them both using JMeter at 1,10, and 40 concurrent requests and found that the Velocity page was having roughly a 2.5 times worse perfomance time then this JSP page. I understand that reflection is expensive but I guess I had never estimated it to be this much worse. Furthermore, on a machine that this little VM/JSP tradeoff was run, when i had 40 requests pounding at the server i saw the CPU rise to 50% utilization when using JSP but to 95% when using the Velocity engine.
Actual stress (not the JSP/VM comparison) was run on Tomcat 3.3.1, JDK 1.3.1 and Solaris 7 with the recommended patch set.
Machine is a 4-CPU machine with 4Gb of RAM and nothing else running on. Network is not a problem.
Any obvious things here that am not seeing or doing wrong ? Or is it simply the way it is.
-michal
Re: Performance
Posted by Scott Farquhar <sc...@atlassian.com>.
Michal Chmielewski wrote:
Actual stress (not the JSP/VM comparison) was run on Tomcat 3.3.1, JDK
1.3.1 and Solaris 7
>
Try running on a faster web container (Orion, or Tomcat 4.X), a better
JVM (1.4.1), and a faster operating system (windows has better JVM than
solaris).
If you want to test velocity, then test it by itself - there are too
many factors involved!
Cheers,
Scott
--
ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support
-------------------------------------------------------
Need a simple, powerful way to track and manage issues?
Try JIRA - http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Performance
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
This is a rather complicated setup to analyze over email, however :
1) I don't mean this to be taken negatively : do you have template
caching on?
2) I have trouble seeing how things would get *slower* with more db
connections. How did you come to the conclusion that you needed more
connections?
geir
On Saturday, February 15, 2003, at 12:53 AM, Michal Chmielewski wrote:
> I think i may need some help regarding optimizing Velocity's
> performance since I had tried everything that I know how.
>
> I've scanned the group and had found fantastic descriptions about
> Velocity's performance; somone mentioned being able to clear 1,000,000
> templates in 1 hour (277 per second); somone else mentioned 1500 /
> second .... but currently i am observing something very different.
>
> To begin with, I have been stressing our app that embeds Velocity
> 1.3.1-rc2. Run#1 was a steady load of 100 users (this is more or less
> your typical database application) viewing a page, filling a form,
> submitting, viewing another page, not a very complicated sequence. I
> was able to squeeze about 7 seconds per HTTP reqeust that required a
> Velocity template merge (so 100/7 = about 14req /sec, about
> 1,234,285/day). I had quickly realized that the DB was a bottleneck in
> Run#1 (so much so that 92% of the 7 seconds of the request was taking
> somehwere in the db layer). [ I am using wall clock, not CPU time. ]
>
> So, for Run#2 I increased the number of db connection accessible to
> the application from 5 to 20. An unexpected result of this was that
> requests were taking *longer* (8-9 seconds) to complete and the
> bottleneck was *not* the database anymore but the Velocity Template
> merges (which happen at the end of the request, when context is ready
> and template is merged). Now, the 95% of the request time was spent
> doing the merges. It seems that since the db operations were
> completing much more quickly, more threads were spending time in the
> final stages of the requests simulaneusly (doing the merges).
>
> I have done the obvious things that I can think off: (1) caching is
> on, (2) reloading is off (3) logger is NULL. The servlet's response
> writer is configured to buffer 128kb of data and when I run the stress
> and ping the server for a reply to a request i can see the reply
> starting after 8-9 seconds and coming down in one nice flush - this
> means to me that the buffer is big enough to hold the whole response
> nicely, so the network is not an issue during merges.
>
> There is only 1 place for the file resource loader to look for
> templates and i can verify by timing that the very first request that
> results in a template fetch is longer then subsequent ones (by a
> factor of 10, which means that Velocity is caching the templates ok
> and not re-parsing them).
>
> To further convince myself, i had put together this simple Velocity
> Template
>
> <html>
> <head>
> <title>Template Merge Test</title>
> <body>
>
> #set($cnt = $event.getOptionalIntParameter("cnt"))
> #if ($cnt < 0)
> #set($cnt = 10)
> #elseif ($cnt > 500)
> #set($cnt = 500)
> #end
>
> <h2>Template Merge test</h2>
>
> Number of loops set to: $cnt
>
> <p>To change this, call this URI with query argument <b>cnt=number</b>,
> where number is the number of loops you want the test to go through
> (max=500)
>
> $formatter.makeAlternator("color","#dd7777","#77dd77","#7777dd")
>
> <hr>
> #foreach($z in [1..$cnt])
> <h2> Table $z of $cnt </h2>
>
> <table border=1 cellpadding=5 cellspacing=0>
> #foreach ($x in [0..25])
> <tr>
> #foreach ($y in [0..10])
> <td bgcolor=$color> ($x,$y) </td> $color.alternate()
> #end
> </tr>
> #end
> </table>
> #end
> </body>
> </html>
>
> and a comparable JSP page.
>
> I had stressed them both using JMeter at 1,10, and 40 concurrent
> requests and found that the Velocity page was having roughly a 2.5
> times worse perfomance time then this JSP page. I understand that
> reflection is expensive but I guess I had never estimated it to be
> this much worse. Furthermore, on a machine that this little VM/JSP
> tradeoff was run, when i had 40 requests pounding at the server i saw
> the CPU rise to 50% utilization when using JSP but to 95% when using
> the Velocity engine.
>
> Actual stress (not the JSP/VM comparison) was run on Tomcat 3.3.1, JDK
> 1.3.1 and Solaris 7 with the recommended patch set.
> Machine is a 4-CPU machine with 4Gb of RAM and nothing else running
> on. Network is not a problem.
>
> Any obvious things here that am not seeing or doing wrong ? Or is it
> simply the way it is.
>
> -michal
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-247-1713(m)
geirm@adeptra.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org