You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Rickard Öberg <ri...@xpedio.com> on 2001/08/06 12:27:10 UTC
Velocity monthlist
Dear WebWorkers,
(velocity-user in CC)
The speed-check monthlist.jsp has been converted to a Velocity template.
You can find it in /velocity/monthlist.vm. It does pretty much the same
thing as monthlist.jsp and is an interesting test of the speed of
Velocity, and also the syntax.
Unfortunately the Velocity engine treats all literal numerals as
integers, and the Counter JavaBean uses long's, hence a bit of
conversion is necessary which clutters up the syntax. This should be
fixable within Velocity I think.
Other than that it is pretty cool. The Velocity engine was very helpful
during development since it gave precise line numbers when an error
occurred.
The source for the VM and JSP can be found here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webwork/webwork/src/resources/web/velocity/monthlist.vm?rev=1.1&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webwork/webwork/src/resources/web/monthlist.jsp?rev=1.3&content-type=text/vnd.viewcvs-markup
The action and JavaBeans did not have to change at all to be used from
Velocity. Nice. I did have to write a WebWork utility class to allow VM
templates to access WebWork functionality such as instantiating Actions
and JavaBeans.
Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
isn't exactly stellar.
Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is very
good.
Running the monthlist.vm on Orion takes about 140ms, which is also very
good.
Running the monthlist.jsp on Orion takes about 140ms, which is, again,
also very good.
Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
>
> "Geir Magnusson Jr." wrote:
> > > Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> > > isn't exactly stellar.
> > > Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is very
> > > good.
> > > Running the monthlist.vm on Orion takes about 140ms, which is also very
> > > good.
> > > Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> > > also very good.
> > >
> > > Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
> > >
> > >
> >
> > This is great!!!
> >
> > We hold our own under Orion? Any plans to test Resin?
>
> Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> 100ms-150ms. Quite good :-)
Ahhhh! That's great.
Here I was worrying about performance while peeking out looking for that
bus - I can focus on that bus now...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: FW: Velocity and JSP speed testing...
Posted by Bojan Smojver <bo...@binarix.com>.
When I switched my projects from JSP to Velocity, I did it more for:
- simplicity of the language (VTL)
- taking away (from web designers) the power to write/execute Java
directly
but if it's fast as well, even better :-)
Bojan
PS. It does take longer to get the first page. Velocity has to start and
all...
Jon Stevens wrote:
>
> Not exactly scientific, but I do trust Rickard to do things correctly...he
> has an existing JSP page for testing and then converted it to
> Velocity...here are the results...
>
> JSP - 240-480ms
> Velocity - 50-70ms
>
> You make the decision.
>
> :-)
>
> -jon
>
> ------ Forwarded Message
> From: Rickard Öberg <ri...@xpedio.com>
> Reply-To: velocity-user@jakarta.apache.org
> Date: Mon, 06 Aug 2001 17:41:37 +0200
> To: velocity-user@jakarta.apache.org
> Cc: Webwork-User <we...@lists.sourceforge.net>
> Subject: Re: Velocity monthlist
>
> Rickard Öberg wrote:
> > Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page
> > a couple of hundred times before checking the time, and it stabilized at
> > scores around 50-70ms. So, that's like, 6 times faster than the same JSP
> > running on Tomcat 3.2. And the VM was direct converted, almost line by
> > line, since the WebWork taglib is very similar to the Velocity
> > directives, so it's a quite fair comparison.
>
> And to make this comparison even more fair, I just tested the JSP page
> on the same Catalina build, and it scored between 240-480ms. So, not
> only is it slower, it is more fluctuating (and I also think I dare say
> that the JSP taglib in WebWork is as optimized as it can be).
>
> Interesting...
>
> /Rickard
>
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: rickard@xpedio.com
>
> ------ End of Forwarded Message
Re: Velocity and JSP speed testing...
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/6/01 7:18 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Mon, 6 Aug 2001, Jon Stevens wrote:
>
>> Not exactly scientific, but I do trust Rickard to do things correctly...he
>> has an existing JSP page for testing and then converted it to
>> Velocity...here are the results...
>>
>> JSP - 240-480ms
>> Velocity - 50-70ms
>>
>
> Frankly, I'm astounded it took you so long to figure out that you had a
> legitimate case on performance ... at least versus Jasper :-).
It wasn't my posting. I was forwarding another posting. So, the "you" should
be directed at the original poster.
That said, the previous results that I had achieved were a quite bit closer
than those though. The above is pretty astounding.
> Try this
> on some other containers and you will find different results. Orion,
> Resin, and WebLogic are supposed to have pretty fast implementations.
Rickard did. Velocity was either on par or faster. Read the Velocity-dev
archives.
> I did ... the code that Jasper generates is not optimized at all, so doing
> a decent optimizing compiler will make a pretty dramatic
> difference. Watch this space. :-)
Ok.
> Craig (who is actually quite happy with Catalina at this point :-)
I'm pretty happy with the container. Jasper still sucks...regardless of it
being a JSP implementation. :-)
p.s. Even though Tomcat is supposed to be more concerned with the R.I.
status, people are using it for more than that and are depending on it. *I
think* it is ludicrous to assume otherwise as well as to force people to
purchase commercial implementations in order to get a decently performing
engine.
-jon
Re: Velocity and JSP speed testing...
Posted by Remy Maucherat <re...@apache.org>.
> Craig R. McClanahan at craigmcc@apache.org wrote:
> >
> >> -jon
> >
> > Craig (who is actually quite happy with Catalina at this point :-)
>
> Never been a fan of JSPs myself, but seeing Velocity (lately I had to
> install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan
of
> that thing either.
>
> But anyway, coming out of the blue on that, I'm pretty damn tired of this
> whole argument about Velocity VS. JSPs thing...
>
> Tomcat IS the R.I. for Servlets AND JSPs, that's what we agreed on with
Sun
> from the very first time, that's what I keep believing into. So, please,
> both of you (yeah, I'm going to say "shut up" to my project lead) SHUT UP.
Behave ;-)
> I don't give a damn on which one is faster/better. We're here to talk
about
> the development of one product. If you were new users being moderated I
> would reject your postings as "OFF-TOPIC".
I don't really agree in general, although here Jon's post is not very
useful, since there are no details at all on the benchmark.
At least, we can use that as a motivation to improve Jasper so we don't look
as bad ;-)
Remy
RE: Velocity and JSP speed testing...
Posted by Paulo Gaspar <pa...@krankikom.de>.
> He is over on the Velocity lists being a pain in the ass still. :-)
>
> I just love him.
I love you too Jon.
> Our last flame war was about me wanting to get rid of the dynamic
> logging in
> Velocity and just make a dependency on Log4J. Eventually, I think he just
> gave up. Now that Ceki has the 25k .jar file, it is no contest.
Yes, after a few servings of Jon's usual "delicate" approach, Jason van
Zyl made a single post where he made sense of it all.
Sometimes Jon is right - he just has some trouble explaining it.
(He tends to explode something in the process.)
=;o)
Have fun,
Paulo
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Tuesday, August 07, 2001 6:31 AM
>
>
> on 8/6/01 9:24 PM, "Christopher Cain" <cc...@mhsoftware.com> wrote:
>
> > Totally OT, bandwidth-wasting, irrelevant musings P.S. ...
> >
> > Where did that Paulo Gaspar cat go? That guy was always
> interesting in a flame
> > war, especially with Jon involved. Man ... dude did NOT like
> Jon, but he sure
> > loved Velocity. I wonder he went ... I really miss those days,
> back when we
> > were all so young and innocent ... it was a simpler time ;-)
> >
> > Anyway, Jon, I always thought that you should have used some of
> those flame
> > posts from Gaspar for some really sweet Velocity advocacy,
> maybe in your mag
> > articles and web site and stuff. I can hardly think of a more compelling
> > advertisement for Velocity than one of those, "Jon is in
> insufferable ass, but
> > I wouldn't use any other solution than Velocity." That speaks volumes.
> >
> > I really do miss that Gaspar guy though ... we liked him :-)
> >
> > - Christopher
>
> He is over on the Velocity lists being a pain in the ass still. :-)
>
> I just love him.
>
> Our last flame war was about me wanting to get rid of the dynamic
> logging in
> Velocity and just make a dependency on Log4J. Eventually, I think he just
> gave up. Now that Ceki has the 25k .jar file, it is no contest.
>
> :-)
>
> p.s. Below is a recent privately sent email that I got about the
> JDJ article
> I wrote...name/company removed to protect this fine enlightened
> individual.
> :-)
>
> -jon
>
Re: Velocity and JSP speed testing...
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/6/01 9:24 PM, "Christopher Cain" <cc...@mhsoftware.com> wrote:
> Totally OT, bandwidth-wasting, irrelevant musings P.S. ...
>
> Where did that Paulo Gaspar cat go? That guy was always interesting in a flame
> war, especially with Jon involved. Man ... dude did NOT like Jon, but he sure
> loved Velocity. I wonder he went ... I really miss those days, back when we
> were all so young and innocent ... it was a simpler time ;-)
>
> Anyway, Jon, I always thought that you should have used some of those flame
> posts from Gaspar for some really sweet Velocity advocacy, maybe in your mag
> articles and web site and stuff. I can hardly think of a more compelling
> advertisement for Velocity than one of those, "Jon is in insufferable ass, but
> I wouldn't use any other solution than Velocity." That speaks volumes.
>
> I really do miss that Gaspar guy though ... we liked him :-)
>
> - Christopher
He is over on the Velocity lists being a pain in the ass still. :-)
I just love him.
Our last flame war was about me wanting to get rid of the dynamic logging in
Velocity and just make a dependency on Log4J. Eventually, I think he just
gave up. Now that Ceki has the 25k .jar file, it is no contest.
:-)
p.s. Below is a recent privately sent email that I got about the JDJ article
I wrote...name/company removed to protect this fine enlightened individual.
:-)
-jon
> Dear Jon,
>
> I have just finished reading your article evaluating JSP in the July issue
> of Java Developers Journal. Thank you for your very thoughtful analysis of
> JSP and the use of alternatives. My company does not use Velocity, but we
> could have written this article years ago. Our team consists of four
> people who are all Java programmers. Three years ago when everybody else
> was just doing out.print lines from servlets, we saw the need for a
> template based approached to embedding reusable code elements in HTML
> pages. So we wrote a template parsing engine that takes in an HTML page,
> parses out tags that look like {%PAGE_VAL namedThis%} and outputs a
> page. The servlet code handles everything a web application ever needs
> such as database connections, SQL, math, array handling, user objects,
> caching, etc. and the templates themselves act in a consequence free
> environment where all errors are caught and simply explained back to the
> designer or user. When a client's project demands custom code, we simple
> extend the basic tag parsing engine and code the processing of the custom
> tag elements.
>
> We built this architecture for convenience and because there was nothing
> like available at at the time. But throughout the emergence of JSP 1.1, we
> have looked to migrate away from our home grown solution to move to a more
> industry standard solution for our clients. The problem is the closer we
> get to developing in JSP, the more we started to really hate it. We hate it
> for all of the reasons you describe in your article. I think one of your
> best points is how JSP is really only a solution for Java
> programmers. That being said, we are a team of all Java programmers, and
> we are still running screaming away from it. As much as we enjoy writing
> code, we don't want a line of it inside our HTML pages.
>
> Thank you very much for thinking outside the JSP box, and helping us
> justify the techniques we believe are best for ourselves and our clients.
RE: Velocity and JSP speed testing...
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Paulo Gaspar <pa...@krankikom.de>:
> Sorry man, I can't make a really good flame war when I agree
> with Jon.
That's okay, buddy. You're back, and that's the important thing. We missed you
is all ;-)
- Christopher
RE: Velocity and JSP speed testing...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Sorry man, I can't make a really good flame war when I agree
with Jon.
But there is still hope: we still flame each other from time
to time (even if on other lists). Nothing as blazing than that
one you remember, but still...
=:o)
Have fun,
Paulo
> -----Original Message-----
> From: Christopher Cain [mailto:ccain@mhsoftware.com]
> Sent: Tuesday, August 07, 2001 6:24 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Velocity and JSP speed testing...
>
>
> Totally OT, bandwidth-wasting, irrelevant musings P.S. ...
>
> Where did that Paulo Gaspar cat go? That guy was always
> interesting in a flame
> war, especially with Jon involved. Man ... dude did NOT like Jon,
> but he sure
> loved Velocity. I wonder he went ... I really miss those days,
> back when we
> were all so young and innocent ... it was a simpler time ;-)
>
> Anyway, Jon, I always thought that you should have used some of
> those flame
> posts from Gaspar for some really sweet Velocity advocacy, maybe
> in your mag
> articles and web site and stuff. I can hardly think of a more compelling
> advertisement for Velocity than one of those, "Jon is in
> insufferable ass, but
> I wouldn't use any other solution than Velocity." That speaks volumes.
>
> I really do miss that Gaspar guy though ... we liked him :-)
>
> - Christopher
>
Re: Velocity and JSP speed testing...
Posted by Christopher Cain <cc...@mhsoftware.com>.
Totally OT, bandwidth-wasting, irrelevant musings P.S. ...
Where did that Paulo Gaspar cat go? That guy was always interesting in a flame
war, especially with Jon involved. Man ... dude did NOT like Jon, but he sure
loved Velocity. I wonder he went ... I really miss those days, back when we
were all so young and innocent ... it was a simpler time ;-)
Anyway, Jon, I always thought that you should have used some of those flame
posts from Gaspar for some really sweet Velocity advocacy, maybe in your mag
articles and web site and stuff. I can hardly think of a more compelling
advertisement for Velocity than one of those, "Jon is in insufferable ass, but
I wouldn't use any other solution than Velocity." That speaks volumes.
I really do miss that Gaspar guy though ... we liked him :-)
- Christopher
Re: Velocity and JSP speed testing...
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
>
> But anyway, coming out of the blue on that, I'm pretty damn tired of
> this whole argument about Velocity VS. JSPs thing...
>
> Tomcat IS the R.I. for Servlets AND JSPs, that's what we agreed on with
> Sun from the very first time, that's what I keep believing into. So,
> please, both of you (yeah, I'm going to say "shut up" to my project lead) SHUT
> UP.
Sure ... what he said! =)
Actually, I don't really have an opinion on the whole JSP vs. Velocity thing,
and for me, personally, all of the asundry posts that make up the Presentation-
Layer Wars don't really thrill me _OR_ offend me. From the posts I've seen over
the past year or so, it wasn't really much of a war anyway. If it _was_ a war,
then as an unbiased observer I'd have to say that JSP pretty much got bombed
back to the stone age ... oops ... did I say that out loud ;-)
Anyway, I just thought I'd take this opportunity to mention that anyone who is
now sitting and staring at their keyboard with nothing to type, given Pier's
official moritorium on the Presentation Wars, you could always kill some time
by kicking around any one of my last several e-mails and giving me any
thoughts/feedback/insight on _anything_ I am trying to accomplish.
*tapping at the monitor* ... is this thing on? :-)
- Christopher
Re: Velocity and JSP speed testing...
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/6/01 7:45 PM, "Pier P. Fumagalli" <pi...@betaversion.org> wrote:
> Never been a fan of JSPs myself, but seeing Velocity (lately I had to
> install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan of
> that thing either.
Installation != Use
Remember the old JServ 1.0 days when it *sucked* to install it, but it was
still pretty damn good software that *you* were proud of?
:-)
> Especially you, Jon. Damn it, we've walked this path together for a very
> long time. And _as_a_friend_ I'm begging you, if you want to keep going on
> with your crusade against JSPs do it, but be wise enough to do it in the
> right places...
Sorry Pier. I think that performance testing and results of Tomcat 4.0 is
perfectly legal here. Especially in the context of competition with JSP.
Lets not fool our users into thinking that the ASF is producing the fastest
JSP implementation. Oh wait. That's obvious. :-)
The fact that I throw in quips about how JSP sucks balls is my own gibberish
that you are just going to have to put up with. Sorry. :-)
-jon
Re: Velocity and JSP speed testing...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Craig R. McClanahan at craigmcc@apache.org wrote:
>
>> -jon
>
> Craig (who is actually quite happy with Catalina at this point :-)
Never been a fan of JSPs myself, but seeing Velocity (lately I had to
install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan of
that thing either.
But anyway, coming out of the blue on that, I'm pretty damn tired of this
whole argument about Velocity VS. JSPs thing...
Tomcat IS the R.I. for Servlets AND JSPs, that's what we agreed on with Sun
from the very first time, that's what I keep believing into. So, please,
both of you (yeah, I'm going to say "shut up" to my project lead) SHUT UP.
I don't give a damn on which one is faster/better. We're here to talk about
the development of one product. If you were new users being moderated I
would reject your postings as "OFF-TOPIC".
Especially you, Jon. Damn it, we've walked this path together for a very
long time. And _as_a_friend_ I'm begging you, if you want to keep going on
with your crusade against JSPs do it, but be wise enough to do it in the
right places...
Thanks...
Pier
Re: FW: Velocity and JSP speed testing...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 6 Aug 2001, Jon Stevens wrote:
> Not exactly scientific, but I do trust Rickard to do things correctly...he
> has an existing JSP page for testing and then converted it to
> Velocity...here are the results...
>
> JSP - 240-480ms
> Velocity - 50-70ms
>
Frankly, I'm astounded it took you so long to figure out that you had a
legitimate case on performance ... at least versus Jasper :-). Try this
on some other containers and you will find different results. Orion,
Resin, and WebLogic are supposed to have pretty fast implementations.
> You make the decision.
>
> :-)
>
I did ... the code that Jasper generates is not optimized at all, so doing
a decent optimizing compiler will make a pretty dramatic
difference. Watch this space. :-)
> -jon
Craig (who is actually quite happy with Catalina at this point :-)
FW: Velocity and JSP speed testing...
Posted by Jon Stevens <jo...@latchkey.com>.
Not exactly scientific, but I do trust Rickard to do things correctly...he
has an existing JSP page for testing and then converted it to
Velocity...here are the results...
JSP - 240-480ms
Velocity - 50-70ms
You make the decision.
:-)
-jon
------ Forwarded Message
From: Rickard Öberg <ri...@xpedio.com>
Reply-To: velocity-user@jakarta.apache.org
Date: Mon, 06 Aug 2001 17:41:37 +0200
To: velocity-user@jakarta.apache.org
Cc: Webwork-User <we...@lists.sourceforge.net>
Subject: Re: Velocity monthlist
Rickard Öberg wrote:
> Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page
> a couple of hundred times before checking the time, and it stabilized at
> scores around 50-70ms. So, that's like, 6 times faster than the same JSP
> running on Tomcat 3.2. And the VM was direct converted, almost line by
> line, since the WebWork taglib is very similar to the Velocity
> directives, so it's a quite fair comparison.
And to make this comparison even more fair, I just tested the JSP page
on the same Catalina build, and it scored between 240-480ms. So, not
only is it slower, it is more fluctuating (and I also think I dare say
that the JSP taglib in WebWork is as optimized as it can be).
Interesting...
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
------ End of Forwarded Message
Re: Velocity monthlist
Posted by Rickard Öberg <ri...@xpedio.com>.
Rickard Öberg wrote:
> Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page
> a couple of hundred times before checking the time, and it stabilized at
> scores around 50-70ms. So, that's like, 6 times faster than the same JSP
> running on Tomcat 3.2. And the VM was direct converted, almost line by
> line, since the WebWork taglib is very similar to the Velocity
> directives, so it's a quite fair comparison.
And to make this comparison even more fair, I just tested the JSP page
on the same Catalina build, and it scored between 240-480ms. So, not
only is it slower, it is more fluctuating (and I also think I dare say
that the JSP taglib in WebWork is as optimized as it can be).
Interesting...
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: Velocity monthlist
Posted by Rickard Öberg <ri...@xpedio.com>.
"Geir Magnusson Jr." wrote:
> Yow.
>
> When you say 'VM', do you mean the templates or VelociMacros? (We call
> the velocimacros VMs...)
Sorry, I meant the template.
> Can you put together a summary? I would love to post this on the
> Velocity site.
When I get the time. I should do this properly and hit the page a couple
of hundred times before taking the score though, which I didn't do
consistently this time.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
>
> Hey
>
> Rickard Öberg wrote:
> > Kasper Nielsen wrote:
> > > > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > > > 100ms-150ms. Quite good :-)
> > > >
> > > > /Rickard
> > >
> > > And now we are at it, have you tested Catalina (Tomcat 4.0)??
> >
> > Just did. 70-100ms :-)
> >
> > Impressive. Very impressive.
>
> Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page
> a couple of hundred times before checking the time, and it stabilized at
> scores around 50-70ms. So, that's like, 6 times faster than the same JSP
> running on Tomcat 3.2. And the VM was direct converted, almost line by
> line, since the WebWork taglib is very similar to the Velocity
> directives, so it's a quite fair comparison.
Yow.
When you say 'VM', do you mean the templates or VelociMacros? (We call
the velocimacros VMs...)
Can you put together a summary? I would love to post this on the
Velocity site.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Velocity monthlist
Posted by Rickard Öberg <ri...@xpedio.com>.
Hey
Rickard Öberg wrote:
> Kasper Nielsen wrote:
> > > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > > 100ms-150ms. Quite good :-)
> > >
> > > /Rickard
> >
> > And now we are at it, have you tested Catalina (Tomcat 4.0)??
>
> Just did. 70-100ms :-)
>
> Impressive. Very impressive.
Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page
a couple of hundred times before checking the time, and it stabilized at
scores around 50-70ms. So, that's like, 6 times faster than the same JSP
running on Tomcat 3.2. And the VM was direct converted, almost line by
line, since the WebWork taglib is very similar to the Velocity
directives, so it's a quite fair comparison.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: newbie question...
Posted by Leon Messerschmidt <le...@opticode.co.za>.
HI Sumit,
There are some nice examples that comes with the Velocity Download.
Also:
http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-templates.html
~ Leon
----- Original Message -----
From: "Sumit Ranjan" <s_...@rti.daimlerchrysler.com>
To: <ve...@jakarta.apache.org>
Sent: Tuesday, August 07, 2001 7:10 AM
Subject: newbie question...
> hi all!
> i am new to velocity...
> can anybody please direct me to any documentations/How Tos on velocity ?
>
> TIA
>
> sumit ranjan
>
newbie question...
Posted by Sumit Ranjan <s_...@rti.daimlerchrysler.com>.
hi all!
i am new to velocity...
can anybody please direct me to any documentations/How Tos on velocity ?
TIA
sumit ranjan
Re: Design question: just trying to understand
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Nick Bauman wrote:
>
> Geir,
>
> >> Now, I'd like to handle exceptions in my own particular way when I
> >> call a method on that $foo reference in there and it turns out to be
> >> bunk.
> >
> > I think we need some clarification on the word 'bunk'.... :)
>
> Well, say, if the template has something like this:
>
> #set ($myString = "blurfl")
> $myString.indexOff("fl") ## ain't no "indexOff" in java.lang.String!
Then what I was talking about wouldn't help you, because
$myString.indexOff() won't throw an exception - it would simply be
rendered as schmoo.
> >> The
> >> reason this is important is because the object model for that $foo may
> >> change from release to release of my product, and I'd like to know if
> >> that change is blowing the merge() call in my code, not in the
> >> Velocity log. The niave thing to do would be something like this:
> >>
> >> try {
> >> VelocityContext context = new VelocityContext();
> >> context.put("foo", objectOfSomeKind);
> >> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
> >> template.merge(context, sw);
> >> } catch (ResourceNotFoundException rnfe) {
> >> // couldn't find it
> >> } catch (ParseErrorException pee) {
> >> // couldn't parse it
> >> } catch (MethodException me) {
> >> // a method call on $foo is bunk
> >> }
> >>
> >> But I can't do that.
> >
> > Why not? We have a MethodInvocationException that propogates out like
> > a Parse.. or Resource... It is thrown when a method call in a template
> > throws an exception.
>
> I'm dumber than I thought possible! You mean to say I _can_ just do
> that?!?! (well, catch a MethodInvocationException, not the MethodException
> in my example) If it's just that easy, than Velocity is just that much
> cooler!!
I have a feeling that we aren't connecting :
I think that what you want is not the ability to catch an exception, but
rather know when a reference is treated like schmoo..?
> >> With Velocity, the correct way to do it is to write a
> >> class that listens for that exception event and register that class
> >> with the context. I get it, but I'd like to know why this technique
> >> was chosen, why not just let the context throw that as an exception?
> >> Or maybe make it tunable in the config?
> >
> > You have a choice. The Event approach is for people who want to catch
> > the exception in-stream, and substitute a value so the rendering can
> > continue.
>
> Woah, JSP can't touch that with a 10' pole, can it? Sorry if I sound like
> I'm preaching to the converted too much, but that is totally slick.
No - that's certainly an area where Velocity and WebMacro shine, in
error handling....
> >> Just asking. Thank you.
> >
> > Does this solve your problem, or did I misinterpret something?
>
> I believe it does! I'll implement it posthaste and report back. Thank you!
I have a feeling that we misunderstood each other - that the MIE won't
solve your problem...
> > geir
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.net
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > Be well, do good work, and keep in touch.
>
> Garrison couldn't have said it better, but you're one of them east-coasters!
> ;)
Hey! Good catch. I keep thinking I should attribute it. I don't think
of it as a brilliant or funny insight than just a really nice sentiment.
I guess I should.
My family has listened to him ever since I can remember. (We're a bunch
of commie-pinko NPR/PRI supporters... :) My father is a huge fan of
Prairie Home, listens to it every week. I catch the Writers Almanac
every now and then driving, which is where I got the quote...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Design question: just trying to understand
Posted by Nick Bauman <ni...@cortexity.com>.
Geir,
>> Now, I'd like to handle exceptions in my own particular way when I
>> call a method on that $foo reference in there and it turns out to be
>> bunk.
>
> I think we need some clarification on the word 'bunk'.... :)
Well, say, if the template has something like this:
#set ($myString = "blurfl")
$myString.indexOff("fl") ## ain't no "indexOff" in java.lang.String!
>> The
>> reason this is important is because the object model for that $foo may
>> change from release to release of my product, and I'd like to know if
>> that change is blowing the merge() call in my code, not in the
>> Velocity log. The niave thing to do would be something like this:
>>
>> try {
>> VelocityContext context = new VelocityContext();
>> context.put("foo", objectOfSomeKind);
>> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
>> template.merge(context, sw);
>> } catch (ResourceNotFoundException rnfe) {
>> // couldn't find it
>> } catch (ParseErrorException pee) {
>> // couldn't parse it
>> } catch (MethodException me) {
>> // a method call on $foo is bunk
>> }
>>
>> But I can't do that.
>
> Why not? We have a MethodInvocationException that propogates out like
> a Parse.. or Resource... It is thrown when a method call in a template
> throws an exception.
I'm dumber than I thought possible! You mean to say I _can_ just do
that?!?! (well, catch a MethodInvocationException, not the MethodException
in my example) If it's just that easy, than Velocity is just that much
cooler!!
>> With Velocity, the correct way to do it is to write a
>> class that listens for that exception event and register that class
>> with the context. I get it, but I'd like to know why this technique
>> was chosen, why not just let the context throw that as an exception?
>> Or maybe make it tunable in the config?
>
> You have a choice. The Event approach is for people who want to catch
> the exception in-stream, and substitute a value so the rendering can
> continue.
Woah, JSP can't touch that with a 10' pole, can it? Sorry if I sound like
I'm preaching to the converted too much, but that is totally slick.
>> Just asking. Thank you.
>
> Does this solve your problem, or did I misinterpret something?
I believe it does! I'll implement it posthaste and report back. Thank you!
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> Be well, do good work, and keep in touch.
Garrison couldn't have said it better, but you're one of them east-coasters!
;)
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Re: Design question: just trying to understand
Posted by Nick Bauman <ni...@cortexity.com>.
Yes, that does solve my problem. Didn't know it was that easy. Which makes
Velocity that much cooler. I'll implement it and report back. Thanks.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Re: Design question [again]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Nick Bauman wrote:
>
> I guess that doesn't work for me, after all. What I'm trying to catch is this:
>
> Tue Aug 07 16:20:52 CDT 2001 [warn]
> org.apache.velocity.runtime.exception.ReferenceException: reference :
> template = msneshopuk/Htmlen_msnruksh.vtl [line 38,column 1] :
> $myString.indexOff("o") is not a valid reference.
>
> I want to be able to handle this in my code instead of it only going through
> Velocity's logging API. If that reference is just bogus, I'd like to know in
> my own code as the result of the merge. How does one do that?
I figured that I misunderstood. Yes, we will have to add an event
handler for this.
geir
> - Thanks
>
> > Nick Bauman wrote:
> >>
> >> Currently, the template rendering pattern for Velocity is such:
> >> ...
> >> try {
> >> VelocityContext context = new VelocityContext();
> >> context.put("foo", objectOfSomeKind);
> >> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
> >> template.merge(context, sw);
> >> } catch (ResourceNotFoundException rnfe) {
> >> // couldn't find it
> >> } catch (ParseErrorException pee) {
> >> // couldn't parse it
> >> }
> >> ...
> >>
> >> Now, I'd like to handle exceptions in my own particular way when I
> >> call a method on that $foo reference in there and it turns out to be
> >> bunk.
> >
> > I think we need some clarification on the word 'bunk'.... :)
> >
> >> The
> >> reason this is important is because the object model for that $foo may
> >> change from release to release of my product, and I'd like to know if
> >> that change is blowing the merge() call in my code, not in the
> >> Velocity log. The niave thing to do would be something like this:
> >>
> >> try {
> >> VelocityContext context = new VelocityContext();
> >> context.put("foo", objectOfSomeKind);
> >> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
> >> template.merge(context, sw);
> >> } catch (ResourceNotFoundException rnfe) {
> >> // couldn't find it
> >> } catch (ParseErrorException pee) {
> >> // couldn't parse it
> >> } catch (MethodException me) {
> >> // a method call on $foo is bunk
> >> }
> >>
> >> But I can't do that.
> >
> > Why not? We have a MethodInvocationException that propogates out like
> > a Parse.. or Resource... It is thrown when a method call in a template
> > throws an exception.
> >
> >> With Velocity, the correct way to do it is to write a
> >> class that listens for that exception event and register that class
> >> with the context. I get it, but I'd like to know why this technique
> >> was chosen, why not just let the context throw that as an exception?
> >> Or maybe make it tunable in the config?
> >
> > You have a choice. The Event approach is for people who want to catch
> > the exception in-stream, and substitute a value so the rendering can
> > continue.
> >
> >> Just asking. Thank you.
> >
> > Does this solve your problem, or did I misinterpret something?
> >
> > geir
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.net
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > Be well, do good work, and keep in touch.
>
> --
> Nick Bauman
> 3600 N. Dupont
> Minneapolis, MN 55412
> Mobile: (612) 232-7120
> SMS: 6122327120@voicestream.net
> Home: (612) 522-0165
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: Design question [again]
Posted by Nick Bauman <ni...@cortexity.com>.
I guess that doesn't work for me, after all. What I'm trying to catch is this:
Tue Aug 07 16:20:52 CDT 2001 [warn]
org.apache.velocity.runtime.exception.ReferenceException: reference :
template = msneshopuk/Htmlen_msnruksh.vtl [line 38,column 1] :
$myString.indexOff("o") is not a valid reference.
I want to be able to handle this in my code instead of it only going through
Velocity's logging API. If that reference is just bogus, I'd like to know in
my own code as the result of the merge. How does one do that?
- Thanks
> Nick Bauman wrote:
>>
>> Currently, the template rendering pattern for Velocity is such:
>> ...
>> try {
>> VelocityContext context = new VelocityContext();
>> context.put("foo", objectOfSomeKind);
>> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
>> template.merge(context, sw);
>> } catch (ResourceNotFoundException rnfe) {
>> // couldn't find it
>> } catch (ParseErrorException pee) {
>> // couldn't parse it
>> }
>> ...
>>
>> Now, I'd like to handle exceptions in my own particular way when I
>> call a method on that $foo reference in there and it turns out to be
>> bunk.
>
> I think we need some clarification on the word 'bunk'.... :)
>
>> The
>> reason this is important is because the object model for that $foo may
>> change from release to release of my product, and I'd like to know if
>> that change is blowing the merge() call in my code, not in the
>> Velocity log. The niave thing to do would be something like this:
>>
>> try {
>> VelocityContext context = new VelocityContext();
>> context.put("foo", objectOfSomeKind);
>> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
>> template.merge(context, sw);
>> } catch (ResourceNotFoundException rnfe) {
>> // couldn't find it
>> } catch (ParseErrorException pee) {
>> // couldn't parse it
>> } catch (MethodException me) {
>> // a method call on $foo is bunk
>> }
>>
>> But I can't do that.
>
> Why not? We have a MethodInvocationException that propogates out like
> a Parse.. or Resource... It is thrown when a method call in a template
> throws an exception.
>
>> With Velocity, the correct way to do it is to write a
>> class that listens for that exception event and register that class
>> with the context. I get it, but I'd like to know why this technique
>> was chosen, why not just let the context throw that as an exception?
>> Or maybe make it tunable in the config?
>
> You have a choice. The Event approach is for people who want to catch
> the exception in-stream, and substitute a value so the rendering can
> continue.
>
>> Just asking. Thank you.
>
> Does this solve your problem, or did I misinterpret something?
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> Be well, do good work, and keep in touch.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
SMS: 6122327120@voicestream.net
Home: (612) 522-0165
Re: Design question: just trying to understand
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Nick Bauman wrote:
>
> Currently, the template rendering pattern for Velocity is such:
> ...
> try {
> VelocityContext context = new VelocityContext();
> context.put("foo", objectOfSomeKind);
> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
> template.merge(context, sw);
> } catch (ResourceNotFoundException rnfe) {
> // couldn't find it
> } catch (ParseErrorException pee) {
> // couldn't parse it
> }
> ...
>
> Now, I'd like to handle exceptions in my own particular way when I call a
> method on that $foo reference in there and it turns out to be bunk.
I think we need some clarification on the word 'bunk'.... :)
> The
> reason this is important is because the object model for that $foo may
> change from release to release of my product, and I'd like to know if that
> change is blowing the merge() call in my code, not in the Velocity log. The
> niave thing to do would be something like this:
>
> try {
> VelocityContext context = new VelocityContext();
> context.put("foo", objectOfSomeKind);
> template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
> template.merge(context, sw);
> } catch (ResourceNotFoundException rnfe) {
> // couldn't find it
> } catch (ParseErrorException pee) {
> // couldn't parse it
> } catch (MethodException me) {
> // a method call on $foo is bunk
> }
>
> But I can't do that.
Why not? We have a MethodInvocationException that propogates out like a
Parse.. or Resource... It is thrown when a method call in a template
throws an exception.
> With Velocity, the correct way to do it is to write a
> class that listens for that exception event and register that class with the
> context. I get it, but I'd like to know why this technique was chosen, why
> not just let the context throw that as an exception? Or maybe make it
> tunable in the config?
You have a choice. The Event approach is for people who want to catch
the exception in-stream, and substitute a value so the rendering can
continue.
> Just asking. Thank you.
Does this solve your problem, or did I misinterpret something?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Design question: just trying to understand
Posted by Nick Bauman <ni...@cortexity.com>.
Currently, the template rendering pattern for Velocity is such:
...
try {
VelocityContext context = new VelocityContext();
context.put("foo", objectOfSomeKind);
template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
template.merge(context, sw);
} catch (ResourceNotFoundException rnfe) {
// couldn't find it
} catch (ParseErrorException pee) {
// couldn't parse it
}
...
Now, I'd like to handle exceptions in my own particular way when I call a
method on that $foo reference in there and it turns out to be bunk. The
reason this is important is because the object model for that $foo may
change from release to release of my product, and I'd like to know if that
change is blowing the merge() call in my code, not in the Velocity log. The
niave thing to do would be something like this:
try {
VelocityContext context = new VelocityContext();
context.put("foo", objectOfSomeKind);
template = Velocity.getTemplate("/bar/baz/blurfl.vtl");
template.merge(context, sw);
} catch (ResourceNotFoundException rnfe) {
// couldn't find it
} catch (ParseErrorException pee) {
// couldn't parse it
} catch (MethodException me) {
// a method call on $foo is bunk
}
But I can't do that. With Velocity, the correct way to do it is to write a
class that listens for that exception event and register that class with the
context. I get it, but I'd like to know why this technique was chosen, why
not just let the context throw that as an exception? Or maybe make it
tunable in the config?
Just asking. Thank you.
--
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
Home: (612) 522-0165
Re: Velocity monthlist
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/6/01 8:03 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> Just did. 70-100ms :-)
>>
>> Impressive. Very impressive.
>
> (My estimation of Catalina was dead wrong :)
>
> Can you test your JSP sample on tomcat 4?
>
> geir
FYI, Catalina has been really nice for Scarab...once they figured out a
couple performance bottlenecks, things have been running quite nicely. I
still think there may be a couple classreloader issues, but for the most
part, things are working nicely.
-jon
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
>
> Hey
>
> Kasper Nielsen wrote:
> > > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > > 100ms-150ms. Quite good :-)
> > >
> > > /Rickard
> >
> > And now we are at it, have you tested Catalina (Tomcat 4.0)??
>
> Just did. 70-100ms :-)
>
> Impressive. Very impressive.
(My estimation of Catalina was dead wrong :)
Can you test your JSP sample on tomcat 4?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Velocity monthlist
Posted by Rickard Öberg <ri...@xpedio.com>.
Hey
Kasper Nielsen wrote:
> > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > 100ms-150ms. Quite good :-)
> >
> > /Rickard
>
> And now we are at it, have you tested Catalina (Tomcat 4.0)??
Just did. 70-100ms :-)
Impressive. Very impressive.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
>
> Kasper Nielsen wrote:
> >
> > ----- Original Message -----
> > From: "Rickard Öberg" <ri...@xpedio.com>
> > To: <ve...@jakarta.apache.org>
> > Sent: Monday, August 06, 2001 3:14 PM
> > Subject: Re: Velocity monthlist
> >
> > > "Geir Magnusson Jr." wrote:
> > > > > Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> > > > > isn't exactly stellar.
> > > > > Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is
> > very
> > > > > good.
> > > > > Running the monthlist.vm on Orion takes about 140ms, which is also
> > very
> > > > > good.
> > > > > Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> > > > > also very good.
> > > > >
> > > > > Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
> > > > >
> > > > >
> > > >
> > > > This is great!!!
> > > >
> > > > We hold our own under Orion? Any plans to test Resin?
> > >
> > > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > > 100ms-150ms. Quite good :-)
> > >
> > > /Rickard
> >
> > And now we are at it, have you tested Catalina (Tomcat 4.0)??
>
Then Rickard wrote -
> Just did. 70-100ms :-)
I had said before :
>
> Tomcat 4.0 I think will be slow - it was written for conformance to the
> 2.3 spec, and it was always clearly stated that optimization would come
> after spec conformance.
>
So I stand corrected! Most excellent. I know Craig McClanahan will be
*thrilled* that Velocity performs so well under Tomcat 4.0.
:)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Kasper Nielsen wrote:
>
> ----- Original Message -----
> From: "Rickard Öberg" <ri...@xpedio.com>
> To: <ve...@jakarta.apache.org>
> Sent: Monday, August 06, 2001 3:14 PM
> Subject: Re: Velocity monthlist
>
> > "Geir Magnusson Jr." wrote:
> > > > Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> > > > isn't exactly stellar.
> > > > Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is
> very
> > > > good.
> > > > Running the monthlist.vm on Orion takes about 140ms, which is also
> very
> > > > good.
> > > > Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> > > > also very good.
> > > >
> > > > Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
> > > >
> > > >
> > >
> > > This is great!!!
> > >
> > > We hold our own under Orion? Any plans to test Resin?
> >
> > Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> > 100ms-150ms. Quite good :-)
> >
> > /Rickard
>
> And now we are at it, have you tested Catalina (Tomcat 4.0)??
And Tomcat 3.3.
Tomcat 4.0 I think will be slow - it was written for conformance to the
2.3 spec, and it was always clearly stated that optimization would come
after spec conformance.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Velocity monthlist
Posted by Kasper Nielsen <ne...@kav.dk>.
----- Original Message -----
From: "Rickard �berg" <ri...@xpedio.com>
To: <ve...@jakarta.apache.org>
Sent: Monday, August 06, 2001 3:14 PM
Subject: Re: Velocity monthlist
> "Geir Magnusson Jr." wrote:
> > > Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> > > isn't exactly stellar.
> > > Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is
very
> > > good.
> > > Running the monthlist.vm on Orion takes about 140ms, which is also
very
> > > good.
> > > Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> > > also very good.
> > >
> > > Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
> > >
> > >
> >
> > This is great!!!
> >
> > We hold our own under Orion? Any plans to test Resin?
>
> Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
> 100ms-150ms. Quite good :-)
>
> /Rickard
And now we are at it, have you tested Catalina (Tomcat 4.0)??
- Kasper
Re: Velocity monthlist
Posted by Rickard Öberg <ri...@xpedio.com>.
"Geir Magnusson Jr." wrote:
> > Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> > isn't exactly stellar.
> > Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is very
> > good.
> > Running the monthlist.vm on Orion takes about 140ms, which is also very
> > good.
> > Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> > also very good.
> >
> > Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
> >
> >
>
> This is great!!!
>
> We hold our own under Orion? Any plans to test Resin?
Just tested on Resin 2.0.1. Didn't stabilize, but somewhere between
100ms-150ms. Quite good :-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: Velocity monthlist
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
> Running the monthlist.vm on JBoss/Tomcat3.2 takes about 340ms, which
> isn't exactly stellar.
> Running the monthlist.vm on JBoss/Jetty takes about 130ms, which is very
> good.
> Running the monthlist.vm on Orion takes about 140ms, which is also very
> good.
> Running the monthlist.jsp on Orion takes about 140ms, which is, again,
> also very good.
>
> Running monthlist.jsp on JBoss/Tomcat3.2 is no fun at all...
>
>
This is great!!!
We hold our own under Orion? Any plans to test Resin?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.