> 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:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
