You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Garth Webb <ga...@zappos.com> on 2004/02/17 22:50:40 UTC

Apache::Registry vs Other PerlHandlers (Was: Re: [OT] Re: Shared Module Vars, Missing Object Methods?)

On Tue, 2004-02-17 at 12:58, Ged Haywood wrote:
[snip]
> I don't think I can add much to what Perrin has said.  If you're up
> against it because you've walked into a heap of Perl scripts that
> grew like Topsy, you probably don't want to spend the time and take
> the risk of making wholesale changes, especially if the thing is
> doing pretty much what it needs to do.

This is exactly the case.  I'd like to redesign everything, but its not
worth the time and risk right now.

>   But I'd echo Perrin's call
> for a bit of design thinking if you're taking it to the next stage
> of its lifecycle.  There's a lot of experience hiding around here
> somewhere, and nothing provokes a longer thread than a thorny issue.
> Not that I need a lot more mail... :)

Right now I think I might try to convert a select few of our most hit
scripts into handlers to see if some performance can be gained.

> > It seems to me that most people these days are using toolkits
> 
> There are probably good reasons for that.  I think Perrin is the one
> who's done most on comparing and contrasting them, but if you want to
> make a contribution you could do worse than take a few of them out for
> a spin and let us know what you find.  By all means ask what other
> people think about them for your situation first.

Right now we use Text::Tmpl which I'm not crazy about (it leaks memory
and is hard to debug), but it seems to be fastest gun in the west for
the minimal features we use (echo'ing vars, loops and simple
conditionals).  I'd like to move to something more feature rich, but
during high load days our 3 servers really break a sweat as it is. 
Benchmarks showed that the bulk of the time was spent in Text::Tmpl, so
its not our code (though that can always stand improvements).

If anyone knows of any other simple C-based templating systems they use
and like, I'd be interested to hear about it!

-- 

 |- Garth Webb       -|
 |- garth@zappos.com -|

Re: Apache::Registry vs Other PerlHandlers (Was: Re: [OT] Re: Shared Module Vars, Missing Object Methods?)

Posted by petersm <pe...@venzia.com>.
Garth Webb <ga...@zappos.com> wrote
> 
> If anyone knows of any other simple C-based templating systems they use
> and like, I'd be interested to hear about it!

I really like HTML::Template. I know it's mostly perl based, but it is known
for being really fast. Plus there are several cacheing options that work with
mod_perl or regular CGI (since you said you need to support both). Plus,
there's the HTML::Template::JIT which compiles your templates down to machine
code, making it even faster.

Michael Peters
Venzia

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: Apache::Registry vs Other PerlHandlers (Was: Re: [OT] Re: Shared Module Vars, Missing Object Methods?)

Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hello again,

On Tue, 17 Feb 2004, Garth Webb wrote:

> Right now I think I might try to convert a select few of our most hit
> scripts into handlers to see if some performance can be gained.
> ...
> during high load days our 3 servers really break a sweat as it is. 

Could be worth mentioning that you might be able to change the
architecture to cut down the resource usage without too much change in
the configuration (and practically none in the code) by using proxy
and/or caching techniques.  These old chestnuts have been roasted here
many a time but there always seems to be another wrinkle when a new
thread turns them over again.  Slap me if I'm stating the obvious. :)

73,
Ged.


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html