You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by will trillich <wi...@serensoft.com> on 2001/06/07 06:02:28 UTC
comparison of templating methods?
<warning type="religious holy war" level="pandora's box">
okay -- there's code (mod_perl modules) and there's html, and we
should keep them separate -- which gives rise to templates...
i've heard of
Apache::PageKit
Apache::Template
AxKit
eXtropia?
HTML::Mason
HTML::Embperl
HTML::Template
OpenBedrock
Template-Toolkit
XPathScript
XSLT
regarding the tools that dovetail into the mod_perl paradigm,
who's got a comparison over relative performance (and other
strengths/weaknesses) of various templating methods?
--
#95: We are waking up and linking to each other. We are watching. But
we are not waiting. -- www.cluetrain.com
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
Posted by Matt Sergeant <ma...@sergeant.org>.
On Mon, 11 Jun 2001, will trillich wrote:
> > At 08:59 AM 6/8/2001 -0500, will trillich wrote:
> > >which of the existing paradigms will the widget farm most
> > >closely resemble? and what are your expectations for tradeoff in
> > >functionality/modularity-vs-performance?
> >
> > 1) What do you mean by your first question?
>
> if i was going to minimize a future learning curve, i'd like to
> be able to jump aboard the widget farm already armed with
> knowledge of how to do something similar. if it's nothing at all
> like mason, but similar to axkit, then (if i expect to be an
> ardent fan of the widget attack) i'd be better off pursuing
> axkit. for example.
Actually I've just built a widget-type system for AxKit, though it's not
documented yet. I've sent a couple of posts to the perl-widget mailing
list about it, though I don't think AxKit is terribly popular with the
users there (but then I suppose you could say that about XML and Perl
users in general).
> > 2) I believe there is nothing being done in the widget farm that would
> > really hinder performance other than being objects with methods. Really
> > without a good object structure then a widget farm is wholly useless.
>
> you're definitely right, there. i'm just noticing that several
> templating methods add "molasses in january" effects to the
> rendering of some pages. of course, there may be more to blame
> in the instance of implementation, than in the implementation
> itself...
I think anyone expecting this stuff to be performant is kidding
themselves. I can get XSP pages back in about 100ms with the current CVS
AxKit, and of course that slows down with many connections. You always pay
for these kind of abstractions.
> thanks for your replies -- we're leaning towards axkit or mason at
> the moment--
Cool :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: comparison of templating methods?
Posted by will trillich <wi...@serensoft.com>.
On Sun, Jun 10, 2001 at 10:36:17PM +0800, Gunther Birznieks wrote:
> At 08:59 AM 6/8/2001 -0500, will trillich wrote:
> >which of the existing paradigms will the widget farm most
> >closely resemble? and what are your expectations for tradeoff in
> >functionality/modularity-vs-performance?
>
> 1) What do you mean by your first question?
if i was going to minimize a future learning curve, i'd like to
be able to jump aboard the widget farm already armed with
knowledge of how to do something similar. if it's nothing at all
like mason, but similar to axkit, then (if i expect to be an
ardent fan of the widget attack) i'd be better off pursuing
axkit. for example.
> 2) I believe there is nothing being done in the widget farm that would
> really hinder performance other than being objects with methods. Really
> without a good object structure then a widget farm is wholly useless.
you're definitely right, there. i'm just noticing that several
templating methods add "molasses in january" effects to the
rendering of some pages. of course, there may be more to blame
in the instance of implementation, than in the implementation
itself...
thanks for your replies -- we're leaning towards axkit or mason at
the moment--
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
Posted by Gunther Birznieks <gu...@extropia.com>.
At 08:59 AM 6/8/2001 -0500, will trillich wrote:
>On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote:
> > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > > HTML::Embperl
> > >
> > >For me, this has one major win over the other toolkits: auto form
> > >population from a hash. The online mortgage application system I
> > >wrote has about 1,800 form fields, which have to be populated with
> > >data from a database. By making the form fields match DB column
> > >names, I can reduce the code to do this to:
> > >
> > > my $data = $dbh->fetchrow_hashref($query);
> > > %fdat = (%fdat, %$data);
> > >
> > >Embperl then parses the form and populates it with the matching
> > >name=>value pairs in %fdat, including select options. Beautiful!
> >
> > Not that it's a reality now, but this is one of the things that the Perl
> > Widget Library project on source forge is hoping to accomplish for
> template
> > languages. It's a cross template way of organizing form information and
> map
> > it to db fields.
> >
> > The reality is that there are many fields that cannot map easily 1-1 to a
> > database as you say. eg a date in a database is usually a date field. But
> > in a form, it might be a combination of 3 form fields (dropdown for month,
> > year and day separately).
>
>which of the existing paradigms will the widget farm most
>closely resemble? and what are your expectations for tradeoff in
>functionality/modularity-vs-performance?
1) What do you mean by your first question?
2) I believe there is nothing being done in the widget farm that would
really hinder performance other than being objects with methods. Really
without a good object structure then a widget farm is wholly useless.
If you need extremely high performance pages than you probably need to code
more low level than throwing abstractions around like widgets.
Please read the following, and then take the conversation to the
widget-specific mailing list if you are interested in talking more about it.
http://www.officevision.com/pub/Widget/
Thanks,
Gunther
>--
>I figure: if a man's gonna gamble, may as well do it
>without plowing. -- Bama Dillert, "Some Came Running"
>
>will@serensoft.com
>http://sourceforge.net/projects/newbiedoc -- we need your brain!
>http://www.dontUthink.com/ -- your brain needs us!
__________________________________________________
Gunther Birznieks (gunther.birznieks@eXtropia.com)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: comparison of templating methods?
Posted by Gerald Richter <ri...@ecos.de>.
> >
> >Such things could be solved by using DBIx::Recordset for database access
and
> >define some filters, which are able to transform the content of a field
> >to/from format you need it.
>
> Well, that assumes everything is a database... "everything I think I see,
> looks like a database to me..."
>
> If you look at PHP's GPC model and then realize that it goes farther into
> allowing other datasources such as S or a DB or a secondary DB if the
first
> one is empty for that field, then you'll see that abstracting it in a
> common way rather than a DBI-specific view is much more powerful and is
> something that applications do occasionally have to do.
>
> Writing a filter is doable but really kind of a hack really.
>
I didn't meant a filter, that filters the html page, that would really be a
hack. What DBIx::Recordset can do is have a filter for every database field,
which does the data conversion (for example to and from a human readable
dateformat).
Of course that's only for database access, but it's out there for some years
and does a good job in many projects for me.
That doesn't mean that there aren't many things that could be done more
general, but somebody has to do it....
I looking forward to the widget library to see which problems it solves.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: comparison of templating methods?
Posted by Gunther Birznieks <gu...@extropia.com>.
At 08:25 PM 6/8/2001 +0200, Gerald Richter wrote:
> > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > > HTML::Embperl
> > >
> > >For me, this has one major win over the other toolkits: auto form
> > >population from a hash. The online mortgage application system I
> > >wrote has about 1,800 form fields, which have to be populated with
> > >data from a database. By making the form fields match DB column
> > >names, I can reduce the code to do this to:
> > >
> > > my $data = $dbh->fetchrow_hashref($query);
> > > %fdat = (%fdat, %$data);
> > >
> > >Embperl then parses the form and populates it with the matching
> > >name=>value pairs in %fdat, including select options. Beautiful!
> >
> > Not that it's a reality now, but this is one of the things that the Perl
> > Widget Library project on source forge is hoping to accomplish for
>template
> > languages. It's a cross template way of organizing form information and
>map
> > it to db fields.
> >
> > The reality is that there are many fields that cannot map easily 1-1 to a
> > database as you say. eg a date in a database is usually a date field. But
> > in a form, it might be a combination of 3 form fields (dropdown for month,
> > year and day separately).
> >
>
>Such things could be solved by using DBIx::Recordset for database access and
>define some filters, which are able to transform the content of a field
>to/from format you need it.
Well, that assumes everything is a database... "everything I think I see,
looks like a database to me..."
If you look at PHP's GPC model and then realize that it goes farther into
allowing other datasources such as S or a DB or a secondary DB if the first
one is empty for that field, then you'll see that abstracting it in a
common way rather than a DBI-specific view is much more powerful and is
something that applications do occasionally have to do.
Writing a filter is doable but really kind of a hack really.
Re: comparison of templating methods?
Posted by Gerald Richter <ri...@ecos.de>.
> At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > HTML::Embperl
> >
> >For me, this has one major win over the other toolkits: auto form
> >population from a hash. The online mortgage application system I
> >wrote has about 1,800 form fields, which have to be populated with
> >data from a database. By making the form fields match DB column
> >names, I can reduce the code to do this to:
> >
> > my $data = $dbh->fetchrow_hashref($query);
> > %fdat = (%fdat, %$data);
> >
> >Embperl then parses the form and populates it with the matching
> >name=>value pairs in %fdat, including select options. Beautiful!
>
> Not that it's a reality now, but this is one of the things that the Perl
> Widget Library project on source forge is hoping to accomplish for
template
> languages. It's a cross template way of organizing form information and
map
> it to db fields.
>
> The reality is that there are many fields that cannot map easily 1-1 to a
> database as you say. eg a date in a database is usually a date field. But
> in a form, it might be a combination of 3 form fields (dropdown for month,
> year and day separately).
>
Such things could be solved by using DBIx::Recordset for database access and
define some filters, which are able to transform the content of a field
to/from format you need it.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: comparison of templating methods?
Posted by will trillich <wi...@serensoft.com>.
On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote:
> At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > HTML::Embperl
> >
> >For me, this has one major win over the other toolkits: auto form
> >population from a hash. The online mortgage application system I
> >wrote has about 1,800 form fields, which have to be populated with
> >data from a database. By making the form fields match DB column
> >names, I can reduce the code to do this to:
> >
> > my $data = $dbh->fetchrow_hashref($query);
> > %fdat = (%fdat, %$data);
> >
> >Embperl then parses the form and populates it with the matching
> >name=>value pairs in %fdat, including select options. Beautiful!
>
> Not that it's a reality now, but this is one of the things that the Perl
> Widget Library project on source forge is hoping to accomplish for template
> languages. It's a cross template way of organizing form information and map
> it to db fields.
>
> The reality is that there are many fields that cannot map easily 1-1 to a
> database as you say. eg a date in a database is usually a date field. But
> in a form, it might be a combination of 3 form fields (dropdown for month,
> year and day separately).
which of the existing paradigms will the widget farm most
closely resemble? and what are your expectations for tradeoff in
functionality/modularity-vs-performance?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
Posted by Gunther Birznieks <gu...@extropia.com>.
At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > HTML::Embperl
>
>For me, this has one major win over the other toolkits: auto form
>population from a hash. The online mortgage application system I
>wrote has about 1,800 form fields, which have to be populated with
>data from a database. By making the form fields match DB column
>names, I can reduce the code to do this to:
>
> my $data = $dbh->fetchrow_hashref($query);
> %fdat = (%fdat, %$data);
>
>Embperl then parses the form and populates it with the matching
>name=>value pairs in %fdat, including select options. Beautiful!
Not that it's a reality now, but this is one of the things that the Perl
Widget Library project on source forge is hoping to accomplish for template
languages. It's a cross template way of organizing form information and map
it to db fields.
The reality is that there are many fields that cannot map easily 1-1 to a
database as you say. eg a date in a database is usually a date field. But
in a form, it might be a combination of 3 form fields (dropdown for month,
year and day separately).
Later,
Gunther
Re: comparison of templating methods?
Posted by jh...@thinkstock.com.
will trillich wrote:
> HTML::Mason
> Template-Toolkit
<tuppence type='mine'>
These are only two I have much experience with. I've found both to be
well written, stable and well supported. TT makes it easier to separate
the logic from the presentation layer IMHO. But every time I code a
project in mason I find myself smiling and thinking 'This is fun', at
least occasionally. Projects seem to come together _much_ faster with
Mason, though overall coding time isn't much different. With Mason you
have to work harder if you want to separate logic & presentation, but
its fairly straightfoward if you put some thought into your component
design ahead of time.
So typically, if I need skinability, or if I need to give edit
capability to html'ers with no perl but light scripting ability I use
TT, otherwise I use Mason.
</tuppence>
J
Re: templating benchmarks...
Posted by Perrin Harkins <pe...@elem.com>.
"Tom Lancaster" <to...@grubby.net> wrote:
> Absolutely. But I'd like to bring up something I've noticed in
benchmarking
> 'real' sites: many, if not all, of the templating solutions appear to
> parse the whole of an html page. This is at least true of Apache::ASP and
> HTML::Mason, which I have used. Is it not ?
Not really. They all cache the page in memory. It is not re-parsed every
time.
> I have produced really dramatic differences in performance in a two-tier
> setup by judicious use of mod_include vs. wholesale proxying of pages
> with dynamic content through to the mod_perl/Apache::ASP server.
[snip]
> Granted, I have other major bottlenecks involved: using Berkeley DB v1.x
> for session state, for one. Perhaps this explains some of it -- maybe the
> proxied header/footer requests never make session calls.
I suspect that it's a combination of the database access and the network
transfer. There is no difference in the amount of parsing going on, since
it's all cached after the first time (per child).
- Perrin
Re: templating benchmarks...
Posted by Tom Lancaster <to...@grubby.net>.
> This benchmark can be very non-representive. If you don't know how to
> optimize each and every "thing" under test, you end up with unfair
> benchmark and come to potentially wrong conclusions. Take TT, add compiled
> template caching on the disk and shared TT object and I bet TT won't be at
> the bottom.
>
> In any case always remember that it's extremely hard to run a fair
> benchmark. I'd say it's almost impossible. The only fair benchmarking can
> be done if you know all the in's and out's of the 'things' under test and
> provide many benchmark tests each exploring a single property and not just
> 'one for all' benchmark.
>
> Of course it's a good thing to have benchmarks, but they all should be
> taken with a grain of salt.
>
Absolutely. But I'd like to bring up something I've noticed in benchmarking
'real' sites: many, if not all, of the templating solutions appear to
parse the whole of an html page. This is at least true of Apache::ASP and
HTML::Mason, which I have used. Is it not ?
I have produced really dramatic differences in performance in a two-tier
setup by judicious use of mod_include vs. wholesale proxying of pages
with dynamic content through to the mod_perl/Apache::ASP server.
For example:
In a situation with 1 lightweight frontend proxy and two backend
mod_perl/Apache::ASP app servers ( with load distributed evenly using
a patched mod_rewrite and its ability to select randomly from a list in a file )
, in one part of the site the dynamic headers and footers are generated by
using <!--#include virtual="/apps/include/pane.html?pane=header&location=$REQUEST_URI" -->, where the file being included is in fact proxied back to the app
servers to receive content; in other parts of the site similarly simple pages
are proxied in their entirety to the app servers.
The results I can produce ( granted only with 'ab' ) are stunningly different:
when I request the header and footer from the app servers using mod_include
plus my modified mod_rewrite ( the stock version refuses to rewrite proxied
requests ), I get up to 600 requests / second. When proxying the whole page
through I get around 6 requests / second.
Granted, I have other major bottlenecks involved: using Berkeley DB v1.x
for session state, for one. Perhaps this explains some of it -- maybe the
proxied header/footer requests never make session calls.
I suspect that the wholesale parsing/eval-ing of html pages also plays a part.
What do y'all think ?
Tom
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
Re: templating benchmarks...
Posted by Stas Bekman <st...@stason.org>.
On Wed, 13 Jun 2001, Perrin Harkins wrote:
> > > wow. template toolkil took a big hit, there. (no mod_perl on
> > > this list? hmm!)
> >
> > This benchmark can be very non-representive. If you don't know how to
> > optimize each and every "thing" under test, you end up with unfair
> > benchmark and come to potentially wrong conclusions. Take TT, add compiled
> > template caching on the disk and shared TT object and I bet TT won't be at
> > the bottom.
>
> I actually helped Joshua tune the TT example a little, and it using a cached
> Template object and caching the templates used in the test in memory. The
> "slowness" comes from the fact that it provides a major feature that the
> others don't, and it is being exercised in this test. The magic dot
> notation which allows templates to say foo.bar.baz, regardless of what kind
> of data structure, object, or code ref "foo", "bar", and "baz" may be takes
> a little more work. Whether it's a good idea or not is left as an exercise
> to the reader, but I will say this: if Template Toolkit is the bottleneck in
> your app's performance, you have either done some serious tuning or written
> a really simple application (like this benchmark).
I stand corrected.
I've tried to provide a general note of not taking any numbers for
granted. Your explanation is as usual the great one :)
> Nevertheless, it's good to see some numbers, if only to convince Andy to
> finish his optimized XS version of the TT stash.
Yeah, it beats our apps' performance badly, with some 8000 calls to
_dotop() in TT in some rendered-data-heavy requests, since we use deeply
nested datastructures like foo.bar.baz. I'll probably have to rework this
if Andy doesn't come up with Stash written in XS. If you plan to work with
the current TT and are going to use lots of vars in loops, consider not to
use hashes deeper than one level, and if you still want to use them,
consider reducing the nesting level wherever possible in the templates by
doing [% baz = foo.bar.baz %] before diving into a loop where foo.bar.baz
will be constantly accessed. (of course relevant for loops with many
iterations).
Surpisingly though, TT is faster than pure Perl when it comes to writing
loops rendering data from relatively deeply nested data structures:
Benchmark: timing 2000 iterations of access_perl, access_tt...
access_perl: 7 wallclock secs ( 7.01 usr + 0.00 sys = 7.01 CPU) @
285.31/s (n=2000)
access_tt: 5 wallclock secs ( 4.19 usr + 0.05 sys = 4.24 CPU) @
471.70/s (n=2000)
Here is the benchmark I've used. (this code is a dream of calendar
programmers, since all months are 31-days long :-) :
use Time::HiRes qw( gettimeofday tv_interval );
use Template;
my $tt = Template->new();
my $data =
{
month_name => [1..12],
day_event => [ map {
[ map { {time=>1,info=>2} } 1..31 ]
} 1..12
],
};
use Benchmark;
timethese(2000,
{
access_perl => \&access_perl,
access_tt => \&access_tt,
});
sub access_tt{
my $output = '';
$tt->process(\*DATA, {data=>$data},\$output);
}
sub access_perl{
my $output = '';
for my $m (0..11){
$output .= "Month: $data->{month_name}[$m]\n";
for my $d (0..30){
my $event = $data->{day_event}[$m][$d];
$output .= "Time: $event->{time}\n";
$output .= "Info: $event->{info}\n";
}
}
}
__DATA__
[% FOR m = [0..11] %]
Month: [% data.month_name.$m %]
[% FOR d = [0..30] %]
[% event = data.day_event.$m.$d %]
Time: [% event.time %]
Info: [% event.info %]
[% END %]
[% END %]
Cool, huh?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: templating benchmarks...
Posted by Perrin Harkins <pe...@elem.com>.
> > wow. template toolkil took a big hit, there. (no mod_perl on
> > this list? hmm!)
>
> This benchmark can be very non-representive. If you don't know how to
> optimize each and every "thing" under test, you end up with unfair
> benchmark and come to potentially wrong conclusions. Take TT, add compiled
> template caching on the disk and shared TT object and I bet TT won't be at
> the bottom.
I actually helped Joshua tune the TT example a little, and it using a cached
Template object and caching the templates used in the test in memory. The
"slowness" comes from the fact that it provides a major feature that the
others don't, and it is being exercised in this test. The magic dot
notation which allows templates to say foo.bar.baz, regardless of what kind
of data structure, object, or code ref "foo", "bar", and "baz" may be takes
a little more work. Whether it's a good idea or not is left as an exercise
to the reader, but I will say this: if Template Toolkit is the bottleneck in
your app's performance, you have either done some serious tuning or written
a really simple application (like this benchmark).
Nevertheless, it's good to see some numbers, if only to convince Andy to
finish his optimized XS version of the TT stash.
- Perrin
Re: templating benchmarks...
Posted by Stas Bekman <st...@stason.org>.
On Fri, 8 Jun 2001, will trillich wrote:
> On Thu, Jun 07, 2001 at 06:48:38AM +0200, Gerald Richter wrote:
> > > regarding the tools that dovetail into the mod_perl paradigm,
> > > who's got a comparison over relative performance (and other
> > > strengths/weaknesses) of various templating methods?
> >
> > There are various discussions on the mod_perl list about this topic in the
> > past (so take a look at the archives). Also there was an start to write such
> > a comparsion, but I am not aware that anybody has really finished it. The
> > only benchmarks I know are from Joshua. I append his mail below.
> >
> > NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only
> > measures the startup overhead of the toolkit, the h2000.xxx tests tends a
> > little bit more towards a real application.
>
> this is interesting information -- perhaps misleading to use the
> microscopic "hello world" but still it gives a starting point:
>
> here i sorted by hits-per-second
>
> > Test Name Test File Hits/sec Bytes/Hit
> > ------------ ---------- ---------- ----------
> > HTML static hello.html 1158.4 311 bytes
> > mod_include SSI hello.shtm 996.6 198 bytes
> > mod_caucho JSP hello.jsp 860.6 230 bytes
> > mod_perl handler hello.benc 852.6 196 bytes
> > mod_php PHP hello.php 734.8 225 bytes
> > Apache::Registry v2.01 CGI Raw hello_raw. 706.4 52 bytes
> > Apache::Dispatch v0.08 handler hello/worl 656.1 196 bytes
> > HTML::Template v2.0 hello.htmp 567.2 198 bytes
> > Apache::SSI v2.16 hello.shtm 559.4 199 bytes
> > Template v2.00 Toolkit hello.tt 522.1 198 bytes
> > Apache::Registry v2.01 CGI.pm hello.reg 458.5 216 bytes
> > HTML::Embperl v2.0a18 hello.epl 458.2 219 bytes
> > Apache::ASP v2.07 hello.asp 390.6 241 bytes
> > Apache::ePerl hello.eper 344.8 217 bytes
> > HTML::Mason v0.895 hello.mas 365.3 197 bytes
>
> i bet CGI would be 200.0 or so... ?
>
> and here's the "handler actualy does some work" set:
>
> > mod_caucho JSP 2000 h2000.jsp 328.9 28964 byte
> > mod_php PHP 2000 h2000.php 261.8 28865 byte
> > HTML::Embperl v2.0a18 2000 h2000.epl 247.3 28809 byte
> > Apache::ASP v2.07 2000 h2000.asp 228.0 28997 byte
> > HTML::Mason v0.895 2000 h2000.mas 222.9 28798 byte
> > Template v2.00 Toolkit 2000 h2000.tt 55.6 28888 byte
>
> wow. template toolkil took a big hit, there. (no mod_perl on
> this list? hmm!)
This benchmark can be very non-representive. If you don't know how to
optimize each and every "thing" under test, you end up with unfair
benchmark and come to potentially wrong conclusions. Take TT, add compiled
template caching on the disk and shared TT object and I bet TT won't be at
the bottom.
In any case always remember that it's extremely hard to run a fair
benchmark. I'd say it's almost impossible. The only fair benchmarking can
be done if you know all the in's and out's of the 'things' under test and
provide many benchmark tests each exploring a single property and not just
'one for all' benchmark.
Of course it's a good thing to have benchmarks, but they all should be
taken with a grain of salt.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
templating benchmarks...
Posted by will trillich <wi...@serensoft.com>.
On Thu, Jun 07, 2001 at 06:48:38AM +0200, Gerald Richter wrote:
> > regarding the tools that dovetail into the mod_perl paradigm,
> > who's got a comparison over relative performance (and other
> > strengths/weaknesses) of various templating methods?
>
> There are various discussions on the mod_perl list about this topic in the
> past (so take a look at the archives). Also there was an start to write such
> a comparsion, but I am not aware that anybody has really finished it. The
> only benchmarks I know are from Joshua. I append his mail below.
>
> NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only
> measures the startup overhead of the toolkit, the h2000.xxx tests tends a
> little bit more towards a real application.
this is interesting information -- perhaps misleading to use the
microscopic "hello world" but still it gives a starting point:
here i sorted by hits-per-second
> Test Name Test File Hits/sec Bytes/Hit
> ------------ ---------- ---------- ----------
> HTML static hello.html 1158.4 311 bytes
> mod_include SSI hello.shtm 996.6 198 bytes
> mod_caucho JSP hello.jsp 860.6 230 bytes
> mod_perl handler hello.benc 852.6 196 bytes
> mod_php PHP hello.php 734.8 225 bytes
> Apache::Registry v2.01 CGI Raw hello_raw. 706.4 52 bytes
> Apache::Dispatch v0.08 handler hello/worl 656.1 196 bytes
> HTML::Template v2.0 hello.htmp 567.2 198 bytes
> Apache::SSI v2.16 hello.shtm 559.4 199 bytes
> Template v2.00 Toolkit hello.tt 522.1 198 bytes
> Apache::Registry v2.01 CGI.pm hello.reg 458.5 216 bytes
> HTML::Embperl v2.0a18 hello.epl 458.2 219 bytes
> Apache::ASP v2.07 hello.asp 390.6 241 bytes
> Apache::ePerl hello.eper 344.8 217 bytes
> HTML::Mason v0.895 hello.mas 365.3 197 bytes
i bet CGI would be 200.0 or so... ?
and here's the "handler actualy does some work" set:
> mod_caucho JSP 2000 h2000.jsp 328.9 28964 byte
> mod_php PHP 2000 h2000.php 261.8 28865 byte
> HTML::Embperl v2.0a18 2000 h2000.epl 247.3 28809 byte
> Apache::ASP v2.07 2000 h2000.asp 228.0 28997 byte
> HTML::Mason v0.895 2000 h2000.mas 222.9 28798 byte
> Template v2.00 Toolkit 2000 h2000.tt 55.6 28888 byte
wow. template toolkil took a big hit, there. (no mod_perl on
this list? hmm!)
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
Posted by Gerald Richter <ri...@ecos.de>.
>
> regarding the tools that dovetail into the mod_perl paradigm,
> who's got a comparison over relative performance (and other
> strengths/weaknesses) of various templating methods?
>
There are various discussions on the mod_perl list about this topic in the
past (so take a look at the archives). Also there was an start to write such
a comparsion, but I am not aware that anybody has really finished it. The
only benchmarks I know are from Joshua. I append his mail below.
NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only
measures the startup overhead of the toolkit, the h2000.xxx tests tends a
little bit more towards a real application.
Gerald
----- Original Message -----
From: "Joshua Chamas" <jo...@chamas.com>
To: "Mod Perl" <mo...@apache.org>
Sent: Saturday, January 06, 2001 12:37 PM
Subject: Linux Hello World 2000, Results In!!
> Hey,
>
> The Hello World 2000 benchmark is complete, and my results are below
> along with the Hello World benchmark. Please feel free to contribute
> h2000 benchmarks for any environment, or suggest changes for those
> in the test suite, download at http://www.chamas.com/bench/hello.tar.gz
>
> The h2000 bench is geared toward web apps with templates.
>
> Please note that I couldn't get a java String->Int type cast right,
> so fudged one line in the h2000.jsp ( fix? ) Also note, as seen
> below, I am using the latest versions of PHP & IBM's Java, but not
> of perl, so the results may not be fair in comparing the languages
> on my platform.
>
> --Josh
>
> ]# ./bench.pl -version -time=60 ( -h for help )
>
> Test Name Test File Hits/sec Total Hits Total Time
sec/Hits Bytes/Hit
> ------------ ---------- ---------- ---------- ----------
---------- ----------
> Apache::ASP v2.07 2000 h2000.asp 228.0 13687 hits 60.03 sec
0.004386 28997 byte
> HTML::Embperl v2.0a18 2000 h2000.epl 247.3 14846 hits 60.04 sec
0.004044 28809 byte
> HTML::Mason v0.895 2000 h2000.mas 222.9 13378 hits 60.01 sec
0.004485 28798 byte
> mod_caucho JSP 2000 h2000.jsp 328.9 19741 hits 60.03 sec
0.003041 28964 byte
> mod_php PHP 2000 h2000.php 261.8 15717 hits 60.04 sec
0.003820 28865 byte
> Template v2.00 Toolkit 2000 h2000.tt 55.6 3336 hits 60.01 sec
0.017987 28888 byte
> Apache::ASP v2.07 hello.asp 390.6 23444 hits 60.01 sec
0.002560 241 bytes
> Apache::Dispatch v0.08 handler hello/worl 656.1 39374 hits 60.01 sec
0.001524 196 bytes
> Apache::ePerl hello.eper 344.8 20687 hits 60.00 sec
0.002900 217 bytes
> Apache::Registry v2.01 CGI Raw hello_raw. 706.4 42394 hits 60.02 sec
0.001416 52 bytes
> Apache::Registry v2.01 CGI.pm hello.reg 458.5 27529 hits 60.03 sec
0.002181 216 bytes
> Apache::SSI v2.16 hello.shtm 559.4 33571 hits 60.01 sec
0.001788 199 bytes
> HTML static hello.html 1158.4 50000 hits 43.16 sec
0.000863 311 bytes
> HTML::Embperl v2.0a18 hello.epl 458.2 27496 hits 60.01 sec
0.002183 219 bytes
> HTML::Mason v0.895 hello.mas 365.3 21925 hits 60.02 sec
0.002737 197 bytes
> HTML::Template v2.0 hello.htmp 567.2 34041 hits 60.01 sec
0.001763 198 bytes
> mod_caucho JSP hello.jsp 860.6 50000 hits 58.10 sec
0.001162 230 bytes
> mod_include SSI hello.shtm 996.6 50000 hits 50.17 sec
0.001003 198 bytes
> mod_perl handler hello.benc 852.6 50000 hits 58.64 sec
0.001173 196 bytes
> mod_php PHP hello.php 734.8 44095 hits 60.01 sec
0.001361 225 bytes
> Template v2.00 Toolkit hello.tt 522.1 31338 hits 60.02 sec
0.001915 198 bytes
>
> Apache Server Header Tokens
> ---------------------------
> (Unix)
> Apache/1.3.14
> OpenSSL/0.9.6
> PHP/4.0.3pl1
> Resin/1.2.1
> mod_perl/1.24
> mod_ssl/2.7.1
>
> PERL Version: 5.00503
>
> JAVA Version: java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
> Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled:
jitc))
>
> Operating System: Linux 2.2.14-5.0smp (root@porky) (gcc egcs-2.91.66) #1
2CPU [gate]
>
>
Re: comparison of templating methods?
Posted by jh...@thinkstock.com.
will trillich wrote:
> HTML::Mason
> Template-Toolkit
<tuppence type='mine'>
These are only two I have much experience with. I've found both to be
well written, stable and well supported. TT makes it easier to separate
the logic from the presentation layer IMHO. But every time I code a
project in mason I find myself smiling and thinking 'This is fun', at
least occasionally. Projects seem to come together _much_ faster with
Mason, though overall coding time isn't much different. With Mason you
have to work harder if you want to separate logic & presentation, but
its fairly straightfoward if you put some thought into your component
design ahead of time.
So typically, if I need skinability, or if I need to give edit
capability to html'ers with no perl but light scripting ability I use
TT, otherwise I use Mason.
</tuppence>
J
Re: comparison of templating methods?
Posted by Chris Strom <cs...@cos.com>.
will trillich <wi...@serensoft.com> writes:
> AxKit
> HTML::Embperl
The two that I've had the most experience with are AxKit and HTML::Embperl,
and I'd recommend them both. They are both well maintained (both released
updates in this week) and the mailing lists for both are very responsive
and helpful.
AxKit presents XML data in whatever format you choose using XSL (or
XPathScript), making it very powerful and giving it staying power (since
it's standards based). I haven't had the need to use some of AxKit's other
features (XPathScript, XSP), but that's because I've been able to
accomplish everything I've needed to with XML/XSLT.
I've been using HTML::Embperl for strict HTML presentation. I've
recently begun to play with HTML::EmbperlObject (part of the same package),
and I like it, a lot. It allows you to define a single file as a "base"
template (or a skin to borrow another term), which is wrapped around
individual components. This allows you to keep all of your standard
headers and footers in a single file, while your forms and results sets can
be defined in separate, self contained templates. Add onto that all of the
capabilities of HTML::Embperl, and you've got quite a nice package.
> XPathScript
> XSLT
These aren't really templating toolkits - just specifications that can be
useful for transforming XML data to whatever format you choose. The AxKit
site has lots of good information and links on both of these.
Re: comparison of templating methods?
Posted by jh...@thinkstock.com.
will trillich wrote:
> HTML::Mason
> Template-Toolkit
<tuppence type='mine'>
These are only two I have much experience with. I've found both to be
well written, stable and well supported. TT makes it easier to separate
the logic from the presentation layer IMHO. But every time I code a
project in mason I find myself smiling and thinking 'This is fun', at
least occasionally. Projects seem to come together _much_ faster with
Mason, though overall coding time isn't much different. With Mason you
have to work harder if you want to separate logic & presentation, but
its fairly straightfoward if you put some thought into your component
design ahead of time.
So typically, if I need skinability, or if I need to give edit
capability to html'ers with no perl but light scripting ability I use
TT, otherwise I use Mason.
</tuppence>
J
Re: comparison of templating methods?
Posted by "T.J. Mather" <tj...@anidea.com>.
On Thu, 7 Jun 2001, Steve Smith wrote:
> > HTML::Embperl
>
> For me, this has one major win over the other toolkits: auto form
> population from a hash. The online mortgage application system I
You may also fill in HTML forms with Apache::ASP and
Apache::PageKit. With PageKit it automatically gets the data from the
request parameters, but you may also set it using the fillinform method
from the Model. Both of these applications use HTML::FillInForm to fill
in the HTML Forms.
Re: comparison of templating methods?
Posted by Steve Smith <st...@isay.com.au>.
> HTML::Embperl
For me, this has one major win over the other toolkits: auto form
population from a hash. The online mortgage application system I
wrote has about 1,800 form fields, which have to be populated with
data from a database. By making the form fields match DB column
names, I can reduce the code to do this to:
my $data = $dbh->fetchrow_hashref($query);
%fdat = (%fdat, %$data);
Embperl then parses the form and populates it with the matching
name=>value pairs in %fdat, including select options. Beautiful!
Steve
Re: comparison of templating methods?
Posted by will trillich <wi...@serensoft.com>.
On Fri, Jun 08, 2001 at 10:49:39AM +0800, Stas Bekman wrote:
> This is your "ultimate" answer :) :
>
> Choosing a Templating System.
> http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263
>
> Hopefully Perrin will release his paper close to the conference.
looking forward to that! thanks.
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
Posted by Stas Bekman <st...@stason.org>.
On Wed, 6 Jun 2001, will trillich wrote:
> <warning type="religious holy war" level="pandora's box">
>
> okay -- there's code (mod_perl modules) and there's html, and we
> should keep them separate -- which gives rise to templates...
>
> i've heard of
> Apache::PageKit
> Apache::Template
> AxKit
> eXtropia?
> HTML::Mason
> HTML::Embperl
> HTML::Template
> OpenBedrock
> Template-Toolkit
> XPathScript
> XSLT
>
> regarding the tools that dovetail into the mod_perl paradigm,
> who's got a comparison over relative performance (and other
> strengths/weaknesses) of various templating methods?
This is your "ultimate" answer :) :
Choosing a Templating System.
http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263
Hopefully Perrin will release his paper close to the conference.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/