You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Charles N. Harvey III" <ch...@alloy.com> on 2002/01/03 22:02:03 UTC
Memory usage and performance
Hey all.
I am trying to make the winning case for Velocity development
and I am getting a few questions about performance. I can
only reassure them so much with, "but its really cool!" and
"its sooo much better than jsp." Actually, sitting someone
down and explaining the difference between a template langauge
and a scripting language is going quite well, and who doesn't
like the fact that Velocity forces MVC.
But one developer had a concern about performance. He is not
sure how Velocity stores/caches the templates (.vm files).
Where do they get stored? How much disk space do they take up?
I was under the impression that they take up the amount of
space of a similarly sized text file. Am I wrong? I know the
servlets cache the templates, but how, and where?
That's it. Past that I don't think people can have much to
argue about with me. ;)
Thanks again.
Charlie Harvey
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Rickard <ri...@middleware-company.com>.
Charles N. Harvey III wrote:
> Ok, I talked to my lead developer and he is concerned about
> scalability. His argument is that jsp is a supported platform
> and that something structured and more widely used will scale
> up for a large site like ours. He has doubts that the Velocity
> platform will be able to support the amount of users we get.
Was he talking about development scalability or performance scalability?
JSP may get you some perceived "scalability" in terms of "more people
know it so it's easier to maintain", but if we're talking performance
scalability it's definitely the other way round. Velocity is goind to
scale waaay better, due to the Java class middle step of JSP.
> Now, I might be crazy, but I think that this doesn't make any
> sense at all. Because the scalability of our site and our
> apps depends on our beans, how efficiently we write our
> classes, and on tomcat. Well, the machine performance too but...
Well, the presentation engine will make a difference too, and quite a
lot depending on what you're site is doing.
> So I guess I am just looking for confirmation. Does using
> Velocity in any way decrease scalability? Thanks again.
AFAICT there are no circumstances where Velocity is worse than JSP, but
a whole lot of circumstances where JSP is worse than JSP.
/Rickard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Jacek Kempski wrote:
> This bloke was me, i reckon. Bojan, if you develop for a product, not a
> project, you sometimes (quite often) don't have access to the final
> platform, because there are quite a lot of them. That's where those
> questions arise, as the understanding of " if" and "why" can tell you
> the behaviour. Sure, you can find out yourself, but that's also where
> mailing lists come (should come) handy. OK, enough.
Yes, it gives you an idea of what you might expect. But I always
remember my experiences with Frontpage (very old version, around 1997),
where if you had a lot of nested tables it would become totally unusable
(i.e. you'd have to wait for minutes for the page to be refreshed on the
screen). The fact that it worked reasonably quick when tables weren't
nested was not indicative at all of the real world situation I had (not
that nesting tables in HTML is such a hot idea anyway). So, whatever
other people told me about Frontpage was simply not applicable, because
I had a very different scenario. That's why I'm always extra careful
when giving people pointers to software usability.
Just today, Henri Gomez (of the Tomcat mod_jk fame) pointed out a bug in
mod_jk 1.2.0 (which is now fixed) that was in there for months, but I
never had any problems because I was never hitting that particular piece
of code through my apps. Software of today is so complicated, multi
layered and versatile, that giving generalised statements about its
speed or any other feature is just too scary. At least for me :-)
> By the way, after several months of intense discussions and hard fights
> our company decided to put the web-part
> on Velocity. It will be embedded in several existing products (Overal
> Equipment Efficiency, Statistical Control, Equipment Tracking and
> Monitoring, Work in Progress, Recipe Management) for the
> Microelectronics and Semiconductor Industry, so there is still something
> to come to "powered by Velocity" section.
> The whole development replaces old, proprietary, pre-servlet solution.
Cool. It's nice to see that more and more commercial projects are
embracing Velocity!
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/8/02 2:09 AM, "Jacek Kempski" <Ja...@camline.com> wrote:
> Hello,
>
> This bloke was me, i reckon. Bojan, if you develop for a product, not a
> project, you sometimes (quite often) don't have access to the final
> platform, because there are quite a lot of them. That's where those
> questions arise, as the understanding of " if" and "why" can tell you
> the behaviour. Sure, you can find out yourself, but that's also where
> mailing lists come (should come) handy. OK, enough.
>
> By the way, after several months of intense discussions and hard fights
> our company decided to put the web-part
> on Velocity. It will be embedded in several existing products (Overal
> Equipment Efficiency, Statistical Control, Equipment Tracking and
> Monitoring, Work in Progress, Recipe Management) for the
> Microelectronics and Semiconductor Industry, so there is still something
> to come to "powered by Velocity" section.
This is great! Can't wait!
> The whole development replaces old, proprietary, pre-servlet solution.
>
> Sincerely,
>
> jacek
>
> Bojan Smojver wrote:
>
>> Nick Bauman wrote:
>>
>>
>>> Seriously, I find other people's benchmarks aren't as valuable as my
>>> own, which is why I did one with Velocity for myself, not just
>>> blindly trusting that Bojan's tests were relevant to my own. This
>>> isn't rocket science, everyone should do this: it'll take you
>>> literally 20 minutes of typing to get the answer.
>>
>>
>>
>> Talking about nailing things on the head!!!
>>
>> A few months back a bloke asked about performance and stability of
>> Tomcat 3.3 (Tomcat Dev list). I had exactly the same answer for him:
>> run 'ab' and find out for yourself. There is NO WAY of applying
>> somebody else's benchmark, with their combo of hardware, OS, JVM,
>> applications, etc. to your own situation, unless the situations are
>> identical (highly unlikely).
>>
>> As I said in my original benchmark e-mails, I only wanted to find out
>> if Velocity and my own servlet can stand ground to JSP's, since
>> authors of JSP technology claim that JSP is fast. Honestly, I would
>> use Velocity even if it was slower.
>>
>> Bojan
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Jacek Kempski <Ja...@camline.com>.
Hello,
This bloke was me, i reckon. Bojan, if you develop for a product, not a
project, you sometimes (quite often) don't have access to the final
platform, because there are quite a lot of them. That's where those
questions arise, as the understanding of " if" and "why" can tell you
the behaviour. Sure, you can find out yourself, but that's also where
mailing lists come (should come) handy. OK, enough.
By the way, after several months of intense discussions and hard fights
our company decided to put the web-part
on Velocity. It will be embedded in several existing products (Overal
Equipment Efficiency, Statistical Control, Equipment Tracking and
Monitoring, Work in Progress, Recipe Management) for the
Microelectronics and Semiconductor Industry, so there is still something
to come to "powered by Velocity" section.
The whole development replaces old, proprietary, pre-servlet solution.
Sincerely,
jacek
Bojan Smojver wrote:
> Nick Bauman wrote:
>
>
>> Seriously, I find other people's benchmarks aren't as valuable as my
>> own, which is why I did one with Velocity for myself, not just
>> blindly trusting that Bojan's tests were relevant to my own. This
>> isn't rocket science, everyone should do this: it'll take you
>> literally 20 minutes of typing to get the answer.
>
>
>
> Talking about nailing things on the head!!!
>
> A few months back a bloke asked about performance and stability of
> Tomcat 3.3 (Tomcat Dev list). I had exactly the same answer for him:
> run 'ab' and find out for yourself. There is NO WAY of applying
> somebody else's benchmark, with their combo of hardware, OS, JVM,
> applications, etc. to your own situation, unless the situations are
> identical (highly unlikely).
>
> As I said in my original benchmark e-mails, I only wanted to find out
> if Velocity and my own servlet can stand ground to JSP's, since
> authors of JSP technology claim that JSP is fast. Honestly, I would
> use Velocity even if it was slower.
>
> Bojan
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Nick Bauman wrote:
> Seriously, I find other people's benchmarks aren't as valuable as my own,
> which is why I did one with Velocity for myself, not just blindly trusting
> that Bojan's tests were relevant to my own. This isn't rocket science,
> everyone should do this: it'll take you literally 20 minutes of typing to
> get the answer.
Talking about nailing things on the head!!!
A few months back a bloke asked about performance and stability of
Tomcat 3.3 (Tomcat Dev list). I had exactly the same answer for him: run
'ab' and find out for yourself. There is NO WAY of applying somebody
else's benchmark, with their combo of hardware, OS, JVM, applications,
etc. to your own situation, unless the situations are identical (highly
unlikely).
As I said in my original benchmark e-mails, I only wanted to find out if
Velocity and my own servlet can stand ground to JSP's, since authors of
JSP technology claim that JSP is fast. Honestly, I would use Velocity
even if it was slower.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Nick Bauman <ni...@cortexity.com>.
> Velocity technology design 'ought' to function pretty efficiently. But
> most of the actual evidence I've come across is anecdotal. That's
Not anectdotal.
http://marc.theaimsgroup.com/?l=velocity-user&m=100270266603014&w=2
> fine, but it's the sort of stuff that we believers believe in. I'm not
> sure how to set up and conduct a reasonable comparison, but I think
> it's needed.
Okay, go do a benchmark then and tell us what you find.
Seriously, I find other people's benchmarks aren't as valuable as my own,
which is why I did one with Velocity for myself, not just blindly trusting
that Bojan's tests were relevant to my own. This isn't rocket science,
everyone should do this: it'll take you literally 20 minutes of typing to
get the answer.
And if it's a corporate-wide decision, then selecting any technology
without even the most cursory test is just stupid anyway, don't you think?
--
Nick Bauman
Cortexity Development
http://www.cortexity.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Terry Steichen wrote:
> However.... Let's not let our enthusiasm for the technology lead us to
> excessive claims. I do realize how simple is the basic VTL structure - but
> it has nuances that can keep one up for a week at a time, until you get it
> (after which it's pretty smooth sailing). The more I use it, the more I
> learn how to better use it. After several months of fairly intense
> exposure, I'm stilll learning new things all the time. Many of them are
> ideas that others in this list have mentioned weeks or months ago, but I
> wasn't smart enough (or perhaps ready enough) to comprehend how these ideas
> could be used for what I wanted to do.
It may sound silly, but I think one of the main advantages of VTL is
what it CANNOT do, rather then what it can. It is that 'cannot do' that
forces more complicated things into the back end, where they belong.
JSP's are just too tempting and that's how most screw ups happen. And by
far the biggest problem with them is that you're actually allowing
designers to create PROGRAMS (since JSP are servlets). That's so uncool
and dangerous that it should be avoided at all cost.
I think more senior Velocity people will confirm that the correct way to
go is to have templates that are as simple as possible (I'm talking
about web here). A few #if and #foreach, maybe a few #parse and #include
and you should be done. The rest HAS to be done behind the scenes and
not exposed to the designer, or there is something seriously wrong with
the whole concept.
> On scalability, that's an issue that will become critical to me personally
> in the near future. I'm convinced that logically the Velocity technology
> design 'ought' to function pretty efficiently. But most of the actual
> evidence I've come across is anecdotal. That's fine, but it's the sort of
> stuff that we believers believe in. I'm not sure how to set up and conduct
> a reasonable comparison, but I think it's needed.
Once again, everybody has to judge for themselves. I think we also have
to distinguish here between Velocity as a concept and the actual
implementation. The fact that there could be bugs in the code, doesn't
mean that Velocity as a concept isn't sound. And the fact that new and
more sophisticated implementation is always in the works only helps.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Terry Steichen <te...@net-frame.com>.
I've been reading this exchange with interest and amusement. I personally
am sold on Velocity. I've worked (initimately) with several other
approaches and realized their shortcomings. The I stumbled on Velocity and
'that's all she wrote' for me.
However.... Let's not let our enthusiasm for the technology lead us to
excessive claims. I do realize how simple is the basic VTL structure - but
it has nuances that can keep one up for a week at a time, until you get it
(after which it's pretty smooth sailing). The more I use it, the more I
learn how to better use it. After several months of fairly intense
exposure, I'm stilll learning new things all the time. Many of them are
ideas that others in this list have mentioned weeks or months ago, but I
wasn't smart enough (or perhaps ready enough) to comprehend how these ideas
could be used for what I wanted to do.
On scalability, that's an issue that will become critical to me personally
in the near future. I'm convinced that logically the Velocity technology
design 'ought' to function pretty efficiently. But most of the actual
evidence I've come across is anecdotal. That's fine, but it's the sort of
stuff that we believers believe in. I'm not sure how to set up and conduct
a reasonable comparison, but I think it's needed.
I've noticed that, given what Velocity can do (particularly using its #parse
and #include directives), I've begun to change my underlying structure to
take advantage of it's power. But this is not an overnight process; it's
more like a prolonged exploration.
Again, I think Velocity is tops and it truly does 'rock'. But I don't think
its benefits jump out and immediately become as obvious to a newcomer as
they are to us 'old-timers.' It's an example of what's called the 'COIK'
fallacy - "Clear Only If Known".
Regards,
Terry
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Charles N. Harvey III wrote:
> Ok, I talked to my lead developer and he is concerned about
> scalability. His argument is that jsp is a supported platform
> and that something structured and more widely used will scale
> up for a large site like ours. He has doubts that the Velocity
> platform will be able to support the amount of users we get.
Interesting. How is scalability defined here exactly?
If it has to do with number of requests that can be served concurrently
and/or through an SMP box, I don't think Velocity is going to suffer at
all when compared to JSP's. It is still Java, so if you have a good SMP
platform (think Linux kernel 2.4.x) and good JVM (think IBM 1.3.0),
you're all set.
If it has to do with development scalability, as some people pointed
out, I think the fact that VTL can be learned in one afternoon is
something JSP's just can't offer. And the clean split between
engineering (i.e. writing Java for business logic and/or controllers)
vs. design (i.e. writing nice looking pages with dynamic content using
VTL) is something that doesn't come naturally in JSP.
And just one other (personal preference) comment. I'm not very strong on
UI type things and I always like to 'get down to the programming
language' as quickly as possible. Velocity enables me to do exactly
that. All I need to do is prepare the objects that will be rendered
later through VTL and I'm all set. How the internals of my applications
work is my own business. I don't have to follow any prescribed method,
which all so usual in JSP world, with all the request dispatching,
forwarding and what not. My thinking was more along the lines of:
- there is a template that eventually has to be hit
- I can easily include other pages in it with #parse and #include and my
controller can help in decision making (i.e. set which ones they are)
- populate the objects
- render: ALL DONE!
Quiz for you lead developer:
MS Windows is very widely used - does that make it good?
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory usage and performance
Posted by Igor Fedulov <if...@outlook.net>.
> Now, I might be crazy, but I think that this doesn't make any
> sense at all. Because the scalability of our site and our
> apps depends on our beans, how efficiently we write our
> classes, and on tomcat. Well, the machine performance too but...
>
> So I guess I am just looking for confirmation. Does using
> Velocity in any way decrease scalability? Thanks again.
I think you guys need to run tests yourself, because either your lead
developer is not challenged enough to switch to servlet/velocity model or
he has a team of people who were witting jsp for years and he don't want
a down time caused by introducing a new framework.
Best regards,
--
HTTP is a stateless protocol, and the Internet is a stateless development
environment
--
Igor Fedulov
E-mail : ifedulov@outlook.net
Work Ph: 773.775.1595
Home Ph: 773.281.8938
Cell Ph: 773.580.5935
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Rickard <ri...@middleware-company.com>.
Nick Bauman wrote:
> re: production scalability> Gotta remember that JSP requires its own
> Servlet for every page. There are some huge limitations with this design
> constraint that are lifted with Velocity.
Espeically considering that javac leaks memory with each invocation..
> re: development scalability> You will find, on average, that a Velocity
> page is about 1/3-2/3 the line count as its corresponding JSP page. To me,
> 30-60% reduction in the size of pages is huge in terms of development.
Also consider the dev-cycle time. With JSP, unless you're using exploded
WAR or EAR files, you have to build a jar file and deploy it. With
Velocity, all you have to do is change the template in your dev
structure, and it will be immediately re-read. This saves HUGE amounts
of time during development.
/Rickard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Nick Bauman wrote:
> re: production scalability> Gotta remember that JSP requires its own
> Servlet for every page. There are some huge limitations with this design
> constraint that are lifted with Velocity.
Thanks for reminding me Nick. I have 1 (ONE) servlet that does ALL
Velocity pages on all my sites. It doesn't get any simpler than that.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory usage and performance
Posted by Nick Bauman <ni...@cortexity.com>.
First of all, my performance benchmarks I posted a few months ago, using
1.1 and then 1.2. I don't have them handy right now, try doing an archive
search.
re: production scalability> Gotta remember that JSP requires its own
Servlet for every page. There are some huge limitations with this design
constraint that are lifted with Velocity.
re: development scalability> You will find, on average, that a Velocity
page is about 1/3-2/3 the line count as its corresponding JSP page. To me,
30-60% reduction in the size of pages is huge in terms of development.
But I think you need to write your own tests to prove it to yourself.
C'mon, go for it!
> Thanks everyone for your support and advice.
> We will be starting new apps in Velocity and porting some very poorly
> coded jsp apps to Velocity. From what I can tell is that it will be a
> little more work in the beginning but once past the initial hurdles
> development will be a breeze. A lot of the initial hurdle is just
> planning - identifying what needs to be accessible by each template.
>
> My push for Velocity as a sitewide development platform is almost won!
>
> Thanks.
>
> Charlie
>
> -----Original Message-----
> From: Barbara Baughman [mailto:baughman@utdallas.edu]
> Sent: Friday, January 04, 2002 1:02 PM
> To: Velocity Users List
> Subject: RE: Memory usage and performance
>
>
> As someone who has developed web applications in both JSP and Velocity,
> I vote for Velocity every day of the week and twice on Sunday.
>
> Don't worry about the transition from JSP to Velocity as far as
> learning a new programming language. The Velocity Servlet is just
> java, and the template language is simple enough for a novice
> programmer to pick up in no time (a few hours ?). The documentation
> and support are very good.
>
> You'll have better control over what a web designer can show to the
> world from your database. The logic of the servlet makes it easier to
> maintain the java code than spreading it over lots of JSP's, keeping
> track of taglibs, and intermixing it all with presentation code. The
> templates (presentation) are separate, so you can change the look and
> feel without ever dealing with java or recompiling, and the changes
> show up
> immediately. Your java programmer doesn't need to know anything about
> HTML or how the data is finally presented.
>
> I'll grant you that porting a JSP application to Velocity is time-
> intensive because the program logic will have to be separated from the
> presentation, but starting a new app with Velocity is a no-brainer.
> It's such an improvement over JSP, I think Velocity will do nothing but
> gain momentum as time goes on.
>
> My boss is impressed at how quickly I can now develop and maintain
> applications -- makes me look good.
>
> Velocity just rocks.
>
> Barbara Baughman
>
> On Fri, 4 Jan 2002, Charles N. Harvey III wrote:
>
>> Ok, I talked to my lead developer and he is concerned about
>> scalability. His argument is that jsp is a supported platform
>> and that something structured and more widely used will scale
>> up for a large site like ours. He has doubts that the Velocity
>> platform will be able to support the amount of users we get.
>>
>> Now, I might be crazy, but I think that this doesn't make any
>> sense at all. Because the scalability of our site and our
>> apps depends on our beans, how efficiently we write our
>> classes, and on tomcat. Well, the machine performance too but...
>>
>> So I guess I am just looking for confirmation. Does using
>> Velocity in any way decrease scalability? Thanks again.
>>
>> Charlie
>>
>> -----Original Message-----
>> From: Nick Bauman [mailto:nick@cortexity.com]
>> Sent: Thursday, January 03, 2002 10:04 PM
>> To: velocity-user@jakarta.apache.org
>> Subject: Re: Memory usage and performance
>>
>>
>> Bojan said:
>>
>> >
>> > I have done some of my own benchmarks, Velocity vs. JSP, and
>> > Velocity was marginally faster in my case. One should read this as:
>> > "It is better and cleaner by design, and yet, it is faster as well".
>>
>> re: marginally faster> This is exactly what my straw tests showed too.
>> I used ab for my tests and a whole slew of different JSP and VMs. So,
>> for what it's worth, I vouch for this statement.
>>
>> > Bojan
>> >
>>
>> --
>> Nick Bauman
>> Cortexity Development
>> http://www.cortexity.com/
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Bauman
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Rickard <ri...@middleware-company.com>.
Charles N. Harvey III wrote:
> Thanks everyone for your support and advice.
> We will be starting new apps in Velocity and porting some very poorly
> coded jsp apps to Velocity. From what I can tell is that it will be
> a little more work in the beginning but once past the initial hurdles
> development will be a breeze. A lot of the initial hurdle is just
> planning - identifying what needs to be accessible by each template.
Yup, that's my thoughts too. The important thing is to look beyond the
initial "pain" and then reap the rewards a little later on.
/Rickard, still coding JSP (pleeease don't ask me why..)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory usage and performance
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Thanks everyone for your support and advice.
We will be starting new apps in Velocity and porting some very poorly
coded jsp apps to Velocity. From what I can tell is that it will be
a little more work in the beginning but once past the initial hurdles
development will be a breeze. A lot of the initial hurdle is just
planning - identifying what needs to be accessible by each template.
My push for Velocity as a sitewide development platform is almost won!
Thanks.
Charlie
-----Original Message-----
From: Barbara Baughman [mailto:baughman@utdallas.edu]
Sent: Friday, January 04, 2002 1:02 PM
To: Velocity Users List
Subject: RE: Memory usage and performance
As someone who has developed web applications in both JSP and Velocity, I
vote for Velocity every day of the week and twice on Sunday.
Don't worry about the transition from JSP to Velocity as far as learning a
new programming language. The Velocity Servlet is just java, and the
template language is simple enough for a novice programmer to pick up in
no time (a few hours ?). The documentation and support are very good.
You'll have better control over what a web designer can show to the world
from your database. The logic of the servlet makes it easier to maintain
the java code than spreading it over lots of JSP's, keeping track of
taglibs, and intermixing it all with presentation code. The templates
(presentation) are separate, so you can change the look and feel without
ever dealing with java or recompiling, and the changes show up
immediately. Your java programmer doesn't need to know anything about
HTML or how the data is finally presented.
I'll grant you that porting a JSP application to Velocity is time-
intensive because the program logic will have to be separated from the
presentation, but starting a new app with Velocity is a no-brainer. It's
such an improvement over JSP, I think Velocity will do nothing but gain
momentum as time goes on.
My boss is impressed at how quickly I can now develop and maintain
applications -- makes me look good.
Velocity just rocks.
Barbara Baughman
On Fri, 4 Jan 2002, Charles N. Harvey III wrote:
> Ok, I talked to my lead developer and he is concerned about
> scalability. His argument is that jsp is a supported platform
> and that something structured and more widely used will scale
> up for a large site like ours. He has doubts that the Velocity
> platform will be able to support the amount of users we get.
>
> Now, I might be crazy, but I think that this doesn't make any
> sense at all. Because the scalability of our site and our
> apps depends on our beans, how efficiently we write our
> classes, and on tomcat. Well, the machine performance too but...
>
> So I guess I am just looking for confirmation. Does using
> Velocity in any way decrease scalability? Thanks again.
>
> Charlie
>
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Thursday, January 03, 2002 10:04 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Memory usage and performance
>
>
> Bojan said:
>
> >
> > I have done some of my own benchmarks, Velocity vs. JSP, and Velocity
> > was marginally faster in my case. One should read this as: "It is
> > better and cleaner by design, and yet, it is faster as well".
>
> re: marginally faster> This is exactly what my straw tests showed too. I
> used ab for my tests and a whole slew of different JSP and VMs. So, for
> what it's worth, I vouch for this statement.
>
> > Bojan
> >
>
> --
> Nick Bauman
> Cortexity Development
> http://www.cortexity.com/
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory usage and performance
Posted by Barbara Baughman <ba...@utdallas.edu>.
As someone who has developed web applications in both JSP and Velocity, I
vote for Velocity every day of the week and twice on Sunday.
Don't worry about the transition from JSP to Velocity as far as learning a
new programming language. The Velocity Servlet is just java, and the
template language is simple enough for a novice programmer to pick up in
no time (a few hours ?). The documentation and support are very good.
You'll have better control over what a web designer can show to the world
from your database. The logic of the servlet makes it easier to maintain
the java code than spreading it over lots of JSP's, keeping track of
taglibs, and intermixing it all with presentation code. The templates
(presentation) are separate, so you can change the look and feel without
ever dealing with java or recompiling, and the changes show up
immediately. Your java programmer doesn't need to know anything about
HTML or how the data is finally presented.
I'll grant you that porting a JSP application to Velocity is time-
intensive because the program logic will have to be separated from the
presentation, but starting a new app with Velocity is a no-brainer. It's
such an improvement over JSP, I think Velocity will do nothing but gain
momentum as time goes on.
My boss is impressed at how quickly I can now develop and maintain
applications -- makes me look good.
Velocity just rocks.
Barbara Baughman
On Fri, 4 Jan 2002, Charles N. Harvey III wrote:
> Ok, I talked to my lead developer and he is concerned about
> scalability. His argument is that jsp is a supported platform
> and that something structured and more widely used will scale
> up for a large site like ours. He has doubts that the Velocity
> platform will be able to support the amount of users we get.
>
> Now, I might be crazy, but I think that this doesn't make any
> sense at all. Because the scalability of our site and our
> apps depends on our beans, how efficiently we write our
> classes, and on tomcat. Well, the machine performance too but...
>
> So I guess I am just looking for confirmation. Does using
> Velocity in any way decrease scalability? Thanks again.
>
> Charlie
>
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Thursday, January 03, 2002 10:04 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Memory usage and performance
>
>
> Bojan said:
>
> >
> > I have done some of my own benchmarks, Velocity vs. JSP, and Velocity
> > was marginally faster in my case. One should read this as: "It is
> > better and cleaner by design, and yet, it is faster as well".
>
> re: marginally faster> This is exactly what my straw tests showed too. I
> used ab for my tests and a whole slew of different JSP and VMs. So, for
> what it's worth, I vouch for this statement.
>
> > Bojan
> >
>
> --
> Nick Bauman
> Cortexity Development
> http://www.cortexity.com/
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory usage and performance
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Ok, I talked to my lead developer and he is concerned about
scalability. His argument is that jsp is a supported platform
and that something structured and more widely used will scale
up for a large site like ours. He has doubts that the Velocity
platform will be able to support the amount of users we get.
Now, I might be crazy, but I think that this doesn't make any
sense at all. Because the scalability of our site and our
apps depends on our beans, how efficiently we write our
classes, and on tomcat. Well, the machine performance too but...
So I guess I am just looking for confirmation. Does using
Velocity in any way decrease scalability? Thanks again.
Charlie
-----Original Message-----
From: Nick Bauman [mailto:nick@cortexity.com]
Sent: Thursday, January 03, 2002 10:04 PM
To: velocity-user@jakarta.apache.org
Subject: Re: Memory usage and performance
Bojan said:
>
> I have done some of my own benchmarks, Velocity vs. JSP, and Velocity
> was marginally faster in my case. One should read this as: "It is
> better and cleaner by design, and yet, it is faster as well".
re: marginally faster> This is exactly what my straw tests showed too. I
used ab for my tests and a whole slew of different JSP and VMs. So, for
what it's worth, I vouch for this statement.
> Bojan
>
--
Nick Bauman
Cortexity Development
http://www.cortexity.com/
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Nick Bauman <ni...@cortexity.com>.
Bojan said:
>
> I have done some of my own benchmarks, Velocity vs. JSP, and Velocity
> was marginally faster in my case. One should read this as: "It is
> better and cleaner by design, and yet, it is faster as well".
re: marginally faster> This is exactly what my straw tests showed too. I
used ab for my tests and a whole slew of different JSP and VMs. So, for
what it's worth, I vouch for this statement.
> Bojan
>
--
Nick Bauman
Cortexity Development
http://www.cortexity.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by Bojan Smojver <bo...@binarix.com>.
Quoting "Charles N. Harvey III" <ch...@alloy.com>:
> Hey all.
> I am trying to make the winning case for Velocity development
> and I am getting a few questions about performance. I can
> only reassure them so much with, "but its really cool!" and
> "its sooo much better than jsp." Actually, sitting someone
> down and explaining the difference between a template langauge
> and a scripting language is going quite well, and who doesn't
> like the fact that Velocity forces MVC.
This is not strictly true. You can use Velocity without being forced into MVC.
Velocity only encourages MVC.
> But one developer had a concern about performance. He is not
> sure how Velocity stores/caches the templates (.vm files).
> Where do they get stored? How much disk space do they take up?
> I was under the impression that they take up the amount of
> space of a similarly sized text file. Am I wrong? I know the
> servlets cache the templates, but how, and where?
Templates get parsed and stored in memory, they aren't cached on disk (unless
you virtual memory system starts swapping). The benefits are that there is no
need to reparse the templates again and that the whole template is a set of Java
objects, so walking through it is as fast as it gets in Java world. I think work
is under way to make caching more flexible, so that the developer can drop the
contents of the cache at will.
I have done some of my own benchmarks, Velocity vs. JSP, and Velocity was
marginally faster in my case. One should read this as: "It is better and cleaner
by design, and yet, it is faster as well".
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory usage and performance
Posted by James Maes <jm...@sportingnews.com>.
We (TSN) have spent alot of time working with Velocity now and did some
analisys on it before we picked it. I would love to help you with some
numbers and getting it approved. What are you looking for exactly?
JSP verses Veloctity
PHP " "
etc...?
Multithread performance?
What is your evnviroment?
What can I do to help you?
(okay, its been a long day....)
On Thursday 03 January 2002 03:02 pm, you wrote:
> Hey all.
> I am trying to make the winning case for Velocity development
> and I am getting a few questions about performance. I can
> only reassure them so much with, "but its really cool!" and
> "its sooo much better than jsp." Actually, sitting someone
> down and explaining the difference between a template langauge
> and a scripting language is going quite well, and who doesn't
> like the fact that Velocity forces MVC.
> But one developer had a concern about performance. He is not
> sure how Velocity stores/caches the templates (.vm files).
> Where do they get stored? How much disk space do they take up?
> I was under the impression that they take up the amount of
> space of a similarly sized text file. Am I wrong? I know the
> servlets cache the templates, but how, and where?
>
> That's it. Past that I don't think people can have much to
> argue about with me. ;)
>
> Thanks again.
>
> Charlie Harvey
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>