You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Morbus Iff <mo...@disobey.com> on 2004/02/13 18:03:42 UTC
Shared Module Vars, Missing Object Methods?
Good day. I'm hoping someone can shed some light on this.
I'm building a series of scripts with the intent to make them usable
under both mod_perl and regular .cgi at the same time: I really don't
want to have multiple versions of the code. "Just add this to your
config file and you're set" sorta thing.
Since I'm building the code from scratch, I am currently using
Apache::Registry, not ::PerlRun. My initial (newb) impression was
that PerlRun is for quick porting, Registry is more proper.
I'm seeing two separate issues that I've yet to find an answer for,
or really, any investigative tips on how I should proceed further.
Likewise, they only happen sporadically (my MaxRequestsPerChild
is set to 30, so once they do happen, they stick around for a few
dozen loads, and then go away again).
Problem one involves (what I believe to be) shared variables
amongst two different scripts, particularly the location
of some template files that the scripts parse and display.
The scripts, installer.cgi and index.cgi, share nearly the exact
same code, except for the location of the templates. The location
of these template files is determined by $0 - if it's installer.cgi,
we set $var to one directory, if it's index.cgi, we set $var to
another directory. This $var setting is done in LibDB::Settings,
which is used by both scripts.
You can see the scripts (installer.cgi, index.cgi), as well
as the other modular code mentioned within, here:
http://cvs.sourceforge.net/viewcvs.py/libdb/LibDB/
What seems to happen is that index.cgi will randomly start
serving data (a template) that installer.cgi previously served,
and vice versa. Refresh enough times, and you'll get an error
message that the $final_template doesn't exist but, from the
file path reported, you can see that it's trying to load an
index.cgi template from an installer.cgi directory (and vice
versa). This smacks to me of shared variables in two places:
$LibDB::Settings::user_template_final (or $settings, the object).
$main::data (either installer.cgi or index.cgi).
I'm not sure why this is (I can make a guess, in hindsight: the
same child that cached $settings in installer.cgi is now using
$settings in index.cgi, but I'm not sure how that could be, since
uesr_template_final is determined at runtime). In the docs,
shared vars are talked about a lot concerning nested subroutines
and lexicals, but even counting mod_perl's handler(), I don't have
any sub's in either index.cgi or installer.cgi. I didn't pursue
much in the lexical direction besides a quick swapping of our()
for my(), which also failed.
Turning on debugging, per the documentation, proved monumental.
One single load of either script created a 217k .out file, and
since I can only reproduce it maybe once out of 100 attempts,
I fear the size and spelunking that would be necessary. I'm
hoping there is an immediately "obvious" fix where such
spelunking is folly.
The second problem I'm having could be related, I'm not sure.
Taking a bird's eye view of things, this is the flow of a single
request to the index.cgi script:
main > LibDB::Template > Text::Template > $tpl > LibDB::DB
What I'm seeing, with the same frequency as the above problem,
is a warning that the object method ->connect can not be found.
LibDB::DB->new returns a LibDB::DB::MySQL class (which itself
uses DBI and DBD::mysql). LibDB::DB::MYSQL contains a ->connect
function, which is a mere wrapper around DBI's. Why it can't be
found perplexes me: enough reloads later, and database access
is working just fine. This doesn't sound like caching whatsoever.
Any ideas? I'm stymied.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
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: Shared Module Vars, Missing Object Methods?
Posted by Morbus Iff <mo...@disobey.com>.
>return undef unless LibDB::DB->supported($user_dbtype);
>
>That would explain why it can't call connect() on the object being returned.
Hmm. The actual error I'm getting, though, DOES mention
LibDB::DB::MySQL - so LibDB::DB seems to be returning
the proper object:
Program fragment delivered error ``Can't locate object
method "connect" via package "LibDB::DB::MySQL" at
[snip]/templates/default/en/variants.html line 31.''
>You should really follow the advice about debugging with -X. It's the
>only way to make the problem repeatable, and you will have a hard time
>solving it if you can't come up with a way to repeat it.
Gotcha.
--
Morbus Iff ( i reserve the right to kill you if i get pissed. )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
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: Shared Module Vars, Missing Object Methods?
Posted by Perrin Harkins <pe...@elem.com>.
Morbus Iff wrote:
> How are other people
> handling user settings? For instance, LibDB::Settings determines a bunch
> of stuff for each and every request, depending on the user environment
> (script being run, the browser's AcceptLanguage, the user's chosen
> template, etc.). Since I want those values to be the same through
> all objects ($s1, $s2, $s3 should return the same setting value
> regardless whether it was changed by $s4), they're all stored in
> a global (to LibDB::Settings) %SETTINGS. How should I handle this
> from mod_perl's standpoint?
To generalize this, the question is how should you make some data that
is specific to this request available from any code that wants to use
it. There are a couple of common approaches.
One of them is to put the data in $r->pnotes(). You can always get at
it from any other code then, like this:
my $value = Apache->request->pnotes('key');
Because you want to make things work in CGI too, you could make an
accessor method that reads and stores this data in pnotes when running
under mod_perl but just shoves it in a global under CGI. The advantage
that pnotes has under mod_perl is that it gets automatically cleared at
the end of every request, avoiding the possibility of caching.
Another way to do it is to structure your code so that there is a place
near the start of each request where you calculate this and put it in a
lexical variable (maybe a hash or an object if it's multiple values),
and then you pass that "context" object (or specific values from it)
around to methods that need it.
>>Make sure you aren't opening a database connection during server
>>startup. Throw in a log statement where you connect to the database and
>>make sure it doesn't happen before you send in a request.
>
> I'm not, but realize that it's never getting to the actual database
> connection: instead, it's telling me that the ->connect routine
> doesn't even exist in the (correct) module.
Usually, a connection before the fork would give you lots of mysterious
errors about losing connections and such, so probably not that. It
looks to me like this just comes back to your "settings" problem again.
From your lLibDB::DB::new:
return undef unless LibDB::DB->supported($user_dbtype);
That would explain why it can't call connect() on the object being returned.
You should really follow the advice about debugging with -X. It's the
only way to make the problem repeatable, and you will have a hard time
solving it if you can't come up with a way to repeat it.
- Perrin
--
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: Shared Module Vars, Missing Object Methods?
Posted by Thomas Schindl <to...@profile.co.at>.
On Sat, 2004-02-14 at 00:46, Morbus Iff wrote:
> >> (my MaxRequestsPerChild is set to 30)
>
> The webhost uses iHTML for ecommerce thingies, and our experience
> with various boxes and server versions is that weird shit happens
> if iHTML isn't cleaned out regularly. This may not be the case (the
> last time we experienced a specific problem with hanging MySQL
> processes associated with iHTML was about a year ago) recently,
> we've yet to find time to adequately run more tests.
>
> >Using a global for that is not such a good idea. Any value you put in
> >there will persist between requests. That is one common source of this
>
> Ignore this next question if too off-topic, then. How are other people
> handling user settings? For instance, LibDB::Settings determines a bunch
> of stuff for each and every request, depending on the user environment
> (script being run, the browser's AcceptLanguage, the user's chosen
> template, etc.). Since I want those values to be the same through
> all objects ($s1, $s2, $s3 should return the same setting value
> regardless whether it was changed by $s4), they're all stored in
> a global (to LibDB::Settings) %SETTINGS. How should I handle this
> from mod_perl's standpoint?
I'm always using a Singleton-Pattern like this:
Config.pm
--------------------8<--------------------
package Config;
our $INSTANCE;
sub new {
my $class = shift;
bless {
val1 => 100,
val2 => "tom",
val3 => 0
}, $class;
}
sub getInstance {
if( ! defined $INSTANCE ){
$INSTANCE = new Config();
}
}
sub getVal {
my $this = shift;
my $valname = shift;
return $this->{$valname};
}
sub setVal {
my $this = shift;
my $valname = shift;
$this->{$valname} = shift
}
sub cleanMeUp {
undef $INSTANCE;
}
--------------------8<--------------------
Handler.pm
--------------------8<--------------------
use Lib1;
use Lib2;
use Config;
sub handler {
## make sure we get a new object
## and not the cashed one
&Config::cleanMeUp()
my $config = &Config::getIntance();
&Lib1::foo();
&Lib2::foo();
print $config->getVal('val1') ## prints 100
print $config->getVal('val2') ## prints tim
print $config->getVal('val3') ## prints 5
}
--------------------8<--------------------
Lib1.pm
--------------------8<--------------------
sub foo {
my $config = &Config::getIntance();
$config->setVal( 'val2', 'tim' );
}
--------------------8<--------------------
Lib2.pm
--------------------8<--------------------
sub foo {
my $config = &Config::getIntance();
$config->setVal( 'val3', 5 );
}
--------------------8<--------------------
>
> >> What I'm seeing, with the same frequency as the above problem,
> >> is a warning that the object method ->connect can not be found.
> >> LibDB::DB->new returns a LibDB::DB::MySQL class (which itself
> >> uses DBI and DBD::mysql). LibDB::DB::MYSQL contains a ->connect
> >> function, which is a mere wrapper around DBI's. Why it can't be
> >> found perplexes me: enough reloads later, and database access
> >> is working just fine. This doesn't sound like caching whatsoever.
> >
> >Make sure you aren't opening a database connection during server
> >startup. Throw in a log statement where you connect to the database and
> >make sure it doesn't happen before you send in a request.
>
> I'm not, but realize that it's never getting to the actual database
> connection: instead, it's telling me that the ->connect routine
> doesn't even exist in the (correct) module.
>
> --
> Morbus Iff ( softcore vulcan pr0n rulezzzzz )
> Technical: http://www.oreillynet.com/pub/au/779
> Culture: http://www.disobey.com/ and http://www.gamegrene.com/
> icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
\\\||///
\\ - - //
( @ @ )
-oOo--( )--oOo----------------------------------------------------------
___ ___ tom schindl
o __ / / / innovative medientechnik planung AG
/ /\/\/ / / /__/ / __ mailto:tom.schindl@profile.co.at
/ / / / /_/ / / /___/ http://www.impire.de
/ voice:+43(512)34193431,fax:+43(512)34193420
Eduard-Bodem-Gasse 6, A-6020 Innsbruck, Austria, Software Engineering
------------------------------------------------------------------------
--
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: Shared Module Vars, Missing Object Methods?
Posted by Morbus Iff <mo...@disobey.com>.
>> (my MaxRequestsPerChild is set to 30)
The webhost uses iHTML for ecommerce thingies, and our experience
with various boxes and server versions is that weird shit happens
if iHTML isn't cleaned out regularly. This may not be the case (the
last time we experienced a specific problem with hanging MySQL
processes associated with iHTML was about a year ago) recently,
we've yet to find time to adequately run more tests.
>Using a global for that is not such a good idea. Any value you put in
>there will persist between requests. That is one common source of this
Ignore this next question if too off-topic, then. How are other people
handling user settings? For instance, LibDB::Settings determines a bunch
of stuff for each and every request, depending on the user environment
(script being run, the browser's AcceptLanguage, the user's chosen
template, etc.). Since I want those values to be the same through
all objects ($s1, $s2, $s3 should return the same setting value
regardless whether it was changed by $s4), they're all stored in
a global (to LibDB::Settings) %SETTINGS. How should I handle this
from mod_perl's standpoint?
>> What I'm seeing, with the same frequency as the above problem,
>> is a warning that the object method ->connect can not be found.
>> LibDB::DB->new returns a LibDB::DB::MySQL class (which itself
>> uses DBI and DBD::mysql). LibDB::DB::MYSQL contains a ->connect
>> function, which is a mere wrapper around DBI's. Why it can't be
>> found perplexes me: enough reloads later, and database access
>> is working just fine. This doesn't sound like caching whatsoever.
>
>Make sure you aren't opening a database connection during server
>startup. Throw in a log statement where you connect to the database and
>make sure it doesn't happen before you send in a request.
I'm not, but realize that it's never getting to the actual database
connection: instead, it's telling me that the ->connect routine
doesn't even exist in the (correct) module.
--
Morbus Iff ( softcore vulcan pr0n rulezzzzz )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
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: Shared Module Vars, Missing Object Methods?
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2004-02-13 at 12:03, Morbus Iff wrote:
> My initial (newb) impression was
> that PerlRun is for quick porting, Registry is more proper.
The main difference is that PerlRun compiles your script every time and
clears out globals in the current namespace every time.
> (my MaxRequestsPerChild
> is set to 30
That's very low. Why did you do that? Were you having problems with
higher numbers?
I use Apache::SizeLimit and set MaxRequestsPerChild to 0 (unlimited).
> The scripts, installer.cgi and index.cgi, share nearly the exact
> same code, except for the location of the templates. The location
> of these template files is determined by $0 - if it's installer.cgi,
> we set $var to one directory, if it's index.cgi, we set $var to
> another directory. This $var setting is done in LibDB::Settings,
> which is used by both scripts.
Using a global for that is not such a good idea. Any value you put in
there will persist between requests. That is one common source of this
sort of "caching" complaint. The other is accidentally creating
closures. Look for situations where you do something like this:
my $foo = 7;
sub bar {
print $foo;
}
That will cache the value of $foo between requests.
> What I'm seeing, with the same frequency as the above problem,
> is a warning that the object method ->connect can not be found.
> LibDB::DB->new returns a LibDB::DB::MySQL class (which itself
> uses DBI and DBD::mysql). LibDB::DB::MYSQL contains a ->connect
> function, which is a mere wrapper around DBI's. Why it can't be
> found perplexes me: enough reloads later, and database access
> is working just fine. This doesn't sound like caching whatsoever.
Make sure you aren't opening a database connection during server
startup. Throw in a log statement where you connect to the database and
make sure it doesn't happen before you send in a request.
That's all I have time for now. Hope that helps a little.
- Perrin
--
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: Shared Module Vars, Missing Object Methods?
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2004-02-13 at 13:49, Morbus Iff wrote:
> * You're starting a script. It needs to
> run under CGI and mod_perl. Would you
>
> * convince the user to go mod_perl or nothing else.
> * maintain two codebases, one for mod_perl, one for cgi.
If you really have to handle both mod_perl and CGI, then
Apache::Registry is a reasonable way to go.
> * You're starting a new project under mod_perl.
There are many different frameworks you could choose for that, from
mod_perl handlers to Apache::ASP. Take a look on the mod_perl site for
more.
- Perrin
--
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: Shared Module Vars, Missing Object Methods?
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
continued...
On Fri, 13 Feb 2004, Morbus Iff wrote:
> I forgot to ask the most obvious:
>
> * You're starting a script. It needs to
> run under CGI and mod_perl.
You'd have to explain that bit to me first.
> * You're starting a new project under mod_perl.
> What would your starting configuration look like,
Probably like in my previous mail today.
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
Re: Shared Module Vars, Missing Object Methods?
Posted by Morbus Iff <mo...@disobey.com>.
>> I'm building a series of scripts with the intent to make them
>> usable under both mod_perl and regular .cgi at the same time
>
>If I were you I wouldn't do that.
>
>> Since I'm building the code from scratch, I am currently using
>> Apache::Registry
>
>If I were you I wouldn't do that either.
I forgot to ask the most obvious:
* You're starting a script. It needs to
run under CGI and mod_perl. Would you
* convince the user to go mod_perl or nothing else.
* maintain two codebases, one for mod_perl, one for cgi.
* You're starting a new project under mod_perl.
What would your starting configuration look like,
recognizing the PerlRun and Registry are "horrible hacks"?
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
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: Shared Module Vars, Missing Object Methods?
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hello again,
I see Perrin's picked up on this thread too, so some of my replies
might be superfluous now but I didn't want to just abandon it.
On Fri, 13 Feb 2004, Morbus Iff wrote:
> >Code handlers, get rid of globals and closures, run 'httpd -X'.
>
> Could you tell me more what you mean by "code handlers"?
I meant write code as handlers. Apache::Registry _is_ a handler.
http://perl.apache.org/docs/1.0/guide/config.html
<Location /foo>
SetHandler perl-script
PerlHandler My::Module
</Location>
> If I "undef" certain things at the end of scripts (like
> undef $settings, undef $final_template, undef $data), would
> that help?
It depends if they're causing the problems in the first place.
Half the time the problem is you don't know what the problem is.
> Are those three variables considered globals to mod_perl
> (they're lexical to index.cgi::main)?
There are two considerations: globals and persistence. Globals are
genreally a Bad Thing in any programming. Under mod_perl, the added
confusion of persistence (which is a kind of good-news-bad-news thing)
can compound problems with any carelessly initialized variables. Best
to pass variables around as parameters and/or use methods if you can.
I'm not personally a big fan of Perl's object-oriented features but a
great deal of mod_perl code is written that way.
> As for -X, wouldn't that merely confirm children caching?
> What would I learn from confirming or denying the behavior
> under -X?
You won't learn anything from it if you don't do it.
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
Re: Shared Module Vars, Missing Object Methods?
Posted by Morbus Iff <mo...@disobey.com>.
>If I were you I wouldn't do that.
>If I were you I wouldn't do that either.
I know my limitations, and I'm sure you know that of mod_perl's.
At this point, I have to lean toward "code" and not "I ran out
of time". Maintaining two codebases (running under vanilla CGI
is a requirement, not a feature) is just impossible in my
current timeframe.
>> I'm seeing two separate issues
>
>Code handlers, get rid of globals and closures, run 'httpd -X'.
Could you tell me more what you mean by "code handlers"?
If I "undef" certain things at the end of scripts (like
undef $settings, undef $final_template, undef $data), would
that help? Are those three variables considered globals
to mod_perl (they're lexical to index.cgi::main)? my()
to our() didn't help.
As for -X, wouldn't that merely confirm children caching?
What would I learn from confirming or denying the behavior
under -X?
Thanks for the reply.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
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: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-02-17 at 14:07, Garth Webb wrote:
> So my question is, what do you think is the better alternative to
> Apache::Registry?
There is nothing terribly wrong with Apache::Registry. The main issue
is that it is emulating a CGI environment to provide backwards
compatibility, and there's no reason to do that for new development
unless you intend to support CGI. If you aren't using them, the extra
moving parts for the emulation are just extra things that can go wrong
or cause problems.
There are certain specific drawbacks to the eval approach used by
Registry, which we have discussed before on the list, but none of them
are serious if you are following a good coding style.
> Do people really have conf files
> with 100's of <Location> directives?
Frankly, if you have 100s of scripts, your application architecture
needs reworking. I typically have less than 10 handlers for an entire,
complex site, with each one representing a single application on the
site.
If I did have 100 handlers, I would use Apache::Dispatch, or generate my
httpd.conf file from a template.
- Perrin
--
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: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-02-17 at 14:22, David Emery wrote:
> You might be looking for something more like this:
>
> http://daemoninc.com/PersistentPerl/
> http://search.cpan.org/~horrocks/PersistentPerl-2.22/
>
> I don't know if it's necessarily *better* than Apache::Registry, but I
> think in your situation it will give you a similar performance boost
> with somewhat less pain.
Sorry, no. It's nearly identical to Apache::Registry in terms of the
kind of code that it tolerates.
- Perrin
--
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: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by David Emery <da...@skiddlydee.com>.
Garth Webb wrote:
> So my question is, what do you think is the better alternative to
> Apache::Registry? If its bad enough that someone like me might have
> written a replacement, where is it? Do people really have conf files
> with 100's of <Location> directives? It seems to me that most people
> these days are using toolkits which take care of this URL location to
> script location automatically, (thus my original question).
You might be looking for something more like this:
http://daemoninc.com/PersistentPerl/
http://search.cpan.org/~horrocks/PersistentPerl-2.22/
I don't know if it's necessarily *better* than Apache::Registry, but I
think in your situation it will give you a similar performance boost
with somewhat less pain.
--
-dave
--
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 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
Apache::Registry vs Other PerlHandlers (Was: Re: [OT] Re: Shared
Module Vars, Missing Object Methods?)
Posted by Garth Webb <ga...@zappos.com>.
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: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Tue, 17 Feb 2004, Garth Webb wrote:
> (Ged, Sorry for the off-list response)
Apology accepted. :) Actually for some reason it found its way to
my backup mail exchanger so it sat there a while unnoticed.
But this thread's not OT at all. Quite the reverse, it addresses an
important issue which we all face from time to time.
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. 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... :)
> 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.
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
Re: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Garth Webb <ga...@zappos.com>.
On Sat, 2004-02-14 at 09:32, Ged Haywood wrote:
> Hi there,
>
> On Fri, 13 Feb 2004, Garth Webb wrote:
>
> > So what is a good alternative to Apache::Registry? My impression was
> > that this is the thing to use unless you want the extra functionality of
> > something like HTML::Mason.
>
> I'm not sure I understand the question. Apache::Registry offers a
> means to simulate a CGI environment, so that many existing CGI scripts
> can run unmodified (or with very little modification) under mod_perl,
> giving a substantial performance boost in most cases. Toolkits like
> HTML::Mason offer very rich sets of features well beyond the scope of
> Apache::Registry and shouldn't really be compared with it.
(Ged, Sorry for the off-list response)
My question was a little confusing. My comparison between
Apache::Registry and HTML::Mason had to do with both assuming the job of
PerlHandler. That is, with either one I don't have to make each script
I write into a Perl module and then have separate <Location> entries
mapping each module to a location in my httpd.conf. With both I can
give a path to my script from the document root and they will take care
of accepting the request and calling my script.
I have around 100 scripts right now, and while I could convert them all
to packages and then set up 100 entries for each in the httpd.conf file,
it seems like that would create a system that is very difficult to
maintain. For instance, right now I can add a new script and it will be
available to the world whereas with the handler method I would need to
restart Apache so that it can read in the new conf.
I could write a package that would handle all the requests and then call
the appropriate scripts for me, but then I've reinvented
Apache::Registry.
So my question is, what do you think is the better alternative to
Apache::Registry? If its bad enough that someone like me might have
written a replacement, where is it? Do people really have conf files
with 100's of <Location> directives? It seems to me that most people
these days are using toolkits which take care of this URL location to
script location automatically, (thus my original question).
> > I read:
> >
> > http://perl.apache.org/docs/1.0/guide/performance.html#Apache__Registry_PerlHandler_vs__Custom_PerlHandler
> >
> > which shows Apache::Registry is slightly slower (but not by much) than
> > writing a custom Handler. In my case I have 100's of scripts I'd have
> > to write custom handlers for which seems like a maintenance nightmare.
>
> The advice I gave about handlers was to someone starting from scratch
> for whom performance clearly isn't the issue. I wouldn't have given
> that advice to someone who wants to run hundreds of existing CGI
> scripts with minimal maintenance issues. I'd probably say now could
> be a good time to look at the 'strict' pragma and the '-w' switch.
>
> > Has someone reinvented Apache::Registry in a way that isn't a horrible hack?
>
> Not as far as I'm aware. :)
>
> Ged.
--
|- Garth Webb -|
|- garth@zappos.com -|
Re: [OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Fri, 13 Feb 2004, Garth Webb wrote:
> So what is a good alternative to Apache::Registry? My impression was
> that this is the thing to use unless you want the extra functionality of
> something like HTML::Mason.
I'm not sure I understand the question. Apache::Registry offers a
means to simulate a CGI environment, so that many existing CGI scripts
can run unmodified (or with very little modification) under mod_perl,
giving a substantial performance boost in most cases. Toolkits like
HTML::Mason offer very rich sets of features well beyond the scope of
Apache::Registry and shouldn't really be compared with it.
> I read:
>
> http://perl.apache.org/docs/1.0/guide/performance.html#Apache__Registry_PerlHandler_vs__Custom_PerlHandler
>
> which shows Apache::Registry is slightly slower (but not by much) than
> writing a custom Handler. In my case I have 100's of scripts I'd have
> to write custom handlers for which seems like a maintenance nightmare.
The advice I gave about handlers was to someone starting from scratch
for whom performance clearly isn't the issue. I wouldn't have given
that advice to someone who wants to run hundreds of existing CGI
scripts with minimal maintenance issues. I'd probably say now could
be a good time to look at the 'strict' pragma and the '-w' switch.
> Has someone reinvented Apache::Registry in a way that isn't a horrible hack?
Not as far as I'm aware. :)
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
[OT] Re: Shared Module Vars, Missing Object Methods?
Posted by Garth Webb <ga...@zappos.com>.
On Fri, 2004-02-13 at 10:26, Ged Haywood wrote:
[snip]
> > Since I'm building the code from scratch, I am currently using
> > Apache::Registry
>
> If I were you I wouldn't do that either.
>
> > My initial (newb) impression was that PerlRun is for quick porting,
> > Registry is more proper.
>
> Nope. Both are horrible hacks.
So what is a good alternative to Apache::Registry? My impression was
that this is the thing to use unless you want the extra functionality of
something like HTML::Mason. I read:
http://perl.apache.org/docs/1.0/guide/performance.html#Apache__Registry_PerlHandler_vs__Custom_PerlHandler
which shows Apache::Registry is slightly slower (but not by much) than
writing a custom Handler. In my case I have 100's of scripts I'd have
to write custom handlers for which seems like a maintenance nightmare.
If I wrote a generalized handler, I'd just be reinventing
Apache::Registry. Has someone reinvented Apache::Registry in a way that
isn't a horrible hack?
--
|- Garth Webb -|
|- garth@zappos.com -|
Re: Shared Module Vars, Missing Object Methods?
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Fri, 13 Feb 2004, Morbus Iff wrote:
> I'm building a series of scripts with the intent to make them usable
> under both mod_perl and regular .cgi at the same time
If I were you I wouldn't do that.
> Since I'm building the code from scratch, I am currently using
> Apache::Registry
If I were you I wouldn't do that either.
> My initial (newb) impression was that PerlRun is for quick porting,
> Registry is more proper.
Nope. Both are horrible hacks.
> I'm seeing two separate issues
Code handlers, get rid of globals and closures, run 'httpd -X'.
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