Apache Hello World Benchmarks Updated
Hey, The Apache Hello World benchmarks are updated at http://chamas.com/bench/ The changes that affect performance numbers include: Set MaxRequestsPerChild to 1000 globally for more realistic run. Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Note that the latter change seemed to have the most benefit for Embperl 2.0, with some benefit for Template Toolkit less ( but some ) for HTML::Mason on the memory usage numbers. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: [Mason] ANNOUNCE: Mason 1.15
On Mon, 14 Oct 2002, Dave Rolsky wrote: Eventually, we'll fork the code base again and start breaking things in preparation for an eventual 1.20 (or maybe some other version number cause we might get to 1.20 just by small bugfix/doc/performance releases), which will incorporate new features such as .NET compliance, full support for _all_ XML specs, and a special NP-problem solving module, plus a brand new set of ginsu knives. Dave, just interesting. What does ginsu knives means :? Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Does Apache::NavBar exist ?
Hi I've just been perusing the docs on perl.apache.com and in the Cute Tricks section there is mention of a module called Apache::NavBar being available from CPAN. I may be blind but I can't find it. Does it exist ? Regards Paul *** Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ***
Re: Does Apache::NavBar exist ?
At 12:01 14.10.2002, [EMAIL PROTECTED] wrote: Hi I've just been perusing the docs on perl.apache.com and in the Cute Tricks section there is mention of a module called Apache::NavBar being available from CPAN. I may be blind but I can't find it. Does it exist ? Hi Paul, Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN still: http://www.cpan.org/authors/id/B/BA/BARRACODE/ Otherwise you can find a copy here: http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Does Apache::NavBar exist ?
On Monday, 2002-10-14 at 12:10:33 +0200, Per Einar Ellefsen wrote: At 12:01 14.10.2002, [EMAIL PROTECTED] wrote: I've just been perusing the docs on perl.apache.com and in the Cute Tricks section there is mention of a module called Apache::NavBar being available from CPAN. I may be blind but I can't find it. Does it exist ? Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN still: http://www.cpan.org/authors/id/B/BA/BARRACODE/ Otherwise you can find a copy here: http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ Really strange. CPAN.pm finds it: cpan m Apache::NavBar Module id = Apache::NavBar DESCRIPTION Navigation bar generator CPAN_USERID MPB (mod_perl book (Doug and Lincoln) [EMAIL PROTECTED]) CPAN_VERSION undef CPAN_FILEContact Author mod_perl book (Doug and Lincoln) [EMAIL PROTECTED] DSLI_STATUS bdpO (beta,developer,perl,object-oriented) INST_FILE(not installed) But it doesn't know there is a copy on CPAN. I guess BarracodE (Charles Day) is not registered as owner. I've Cc'ed the people involved. Lincoln, Doug, is this cleared with you? Andreas, if/when it is, can you transfer the module? HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
Re: [Mason] ANNOUNCE: Mason 1.15
On Mon, Oct 14, 2002 at 11:50:09AM +0400, Oleg Bartunov wrote: On Mon, 14 Oct 2002, Dave Rolsky wrote: Eventually, we'll fork the code base again and start breaking things in preparation for an eventual 1.20 (or maybe some other version number cause we might get to 1.20 just by small bugfix/doc/performance releases), which will incorporate new features such as .NET compliance, full support for _all_ XML specs, and a special NP-problem solving module, plus a brand new set of ginsu knives. Dave, just interesting. What does ginsu knives means :? If you haven't had prolonged exposure to US TV you can't understand this reference. My memory is quite vague about it but I think they used to throw in a set of free ginsu knives (think sushi) for people who would buy some crap on the TV shopping program. The general idea of ginsu knives is to entice prospects (mason users) to adopt a product (Mason 1.15) more readily by adding to the package an unrelated free bonus (Dave's joke about ginsu knives ;-).
Re: Does Apache::NavBar exist ?
That's right. CPAN is telling you to contact Doug and Me. Lincoln Does it exist ? Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN still: http://www.cpan.org/authors/id/B/BA/BARRACODE/ Otherwise you can find a copy here: http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ Really strange. CPAN.pm finds it: cpan m Apache::NavBar Module id = Apache::NavBar DESCRIPTION Navigation bar generator CPAN_USERID MPB (mod_perl book (Doug and Lincoln) [EMAIL PROTECTED]) CPAN_VERSION undef CPAN_FILEContact Author mod_perl book (Doug and Lincoln) [EMAIL PROTECTED] DSLI_STATUS bdpO (beta,developer,perl,object-oriented) INST_FILE(not installed) But it doesn't know there is a copy on CPAN. I guess BarracodE (Charles Day) is not registered as owner. I've Cc'ed the people involved. Lincoln, Doug, is this cleared with you? Andreas, if/when it is, can you transfer the module? HTH, Lupe Christoph
[Very OT] Re: [Mason] ANNOUNCE: Mason 1.15
On Monday, 2002-10-14 at 13:26:19 +0200, Louis-David Mitterrand wrote: On Mon, Oct 14, 2002 at 11:50:09AM +0400, Oleg Bartunov wrote: On Mon, 14 Oct 2002, Dave Rolsky wrote: Dave, just interesting. What does ginsu knives means :? If you haven't had prolonged exposure to US TV you can't understand this reference. My memory is quite vague about it but I think they used to throw in a set of free ginsu knives (think sushi) for people who would buy some crap on the TV shopping program. We have this kind of TV ads on German TV now, too. Badly dubbed. So badly it's getting worth watching if you have a cheap sense of humor ... I sometimes make a mistake channel hopping and land on such a channel. Immediate cringes and the inability to use the remote control are the consequence. So I have to watch the stuff until I'm recovered. No free knives as far as I can tell, though. They could try it, Sushi is very much En Vogue here. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
Re: [Very, VERY OT] Re: [Mason] ANNOUNCE: Mason 1.15
Dave, just interesting. What does ginsu knives means :? throw in a set of free ginsu knives (think sushi) for people who would buy some crap on the TV shopping program. We have this kind of TV ads on German TV now, too. Badly dubbed. So badly it's getting worth watching if you have a cheap sense of humor Do they still saw up the cola can and then slice the tomato? =o) Yeah, I know, I'm showing my age __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? Is the data that you're passing to the template correct? Throw in some warn statements. Run it in the debugger if you need to. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote: Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? I have checked the above, and I have lots of warns spaced around so I can watch things in the error log. Is the data that you're passing to the template correct? That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Thanks again, Eric Throw in some warn statements. Run it in the debugger if you need to. - Perrin (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do the connect
in the new() vs up top outside of a sub.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them
ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from
orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
I did this, I was a little scared about calling $dbh-finish() but I did
what you said, and yes life is good I don't notice a speed difference.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
I have no idea why I put off doing that for so long. But that is done now as
well.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: I wanted the DBH to be global since just about every sub in Holds does a query of some sort. Three options: 1) Pass it to every sub 2) Make a utility sub that returns a dbh and call it from each sub. (Sounds like you already made one of these.) 3) Stuff it in $r-pnotes(), where it will get cleaned up after each request. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's been discussed quite a bit in various places. It is now documented in the perlobj man page: http://perldoc.com/perl5.8.0/pod/perlobj.html#Indirect-Object-Syntax - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI and CGI::Application with lots of modules. (fwd)
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
RE: Apache::DBI and CGI::Application with lots of modules.
Hey Eric --
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do
the connect
in the new() vs up top outside of a sub.
CGI::Application has a facility which is intended to solve exactly this type
of problem -- the param() method. The param() method allows you to stash a
property (such as a $dbh) in your CGI::Application-based object which can be
retrieved anywhere. I typically connect to the database in my setup()
method and stash my $dbh for use later:
package My::WebApp;
use strict;
use base qw/CGI::Application/;
sub setup {
my $self = shift;
$self-start_mode('start');
$self-run_modes(
'start' = 'run_mode_method'
);
my $dbh = $self-connect_to_database();
$self-param('DBH', $dbh);
}
sub run_mode_method {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
my $output = '';
# ...etc
return $output;
}
Furthermore, in order to disconnect, the teardown() method may be used:
sub teardown {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
$dbh-disconnect();
}
Refer to the CGI::Application POD for details on teardown() and param().
Regarding connecting to the database, I also urge you to encapsulate your
connection code. On my projects I always get things started by creating a
Perl module which I use whenever I need a database connection:
package My::DatabaseCreds;
use DBI;
sub new_dbh {
my $dbh = DBI-connect()
die (Can't connect: .$DBI::errstr) unless ($dbh);
return $dbh;
}
(This isn't exactly the code I use -- I actually have a module which I
sub-class, but you get the idea.)
The benefit of creating a module is that (1) all your Perl code can use this
module so that (2) should it ever have to change you can change it in one
place.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
My guess is that Perrin was referring to your use of the indirect
notation, as opposed to the arrow notation:
Indirect:
my $holdcheck = new Holds()
Arrow:
my $holdcheck = Holds-new()
Many people (myself included) prefer the arrow notation. In general, the
arrow notation tends to be less ambiguous, particularly when it comes to
combining method calls with arguments.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
Re: migrating from Apache to iPlanet; any mod_perl counterpart? [FOUND?]
I just got this note from Dennis, and it looks like (at first cursory glance) *EXACTLY* what I wanted (God bless you Dennis! =o) I forward it to the list for the benefit of others that might find it helpful in similar situations. I have removed Dennis' email address and phone number, in case he didn't want them shared; I trust the rest of the note is sufficiently impersonal that he won't mind me reposting it to the list. Paul --- Dennis Daupert address deleted wrote: Hi Paul, Although I've not had the time or mandate to get into the perl/nsapi connection, I run several iPlanet web servers, and remembered at some not-too-distant time ago reading in the iPlanet README about perl and nsapi I did a google on perl and nsapi, and got some hits such as: http://www.perldoc.com/cpan/Netscape/Server.html Here's a sample article from the iPlanet knowledgebase pertaining to nsapi equivalents to Apache Addhandler command: http://knowledgebase.iplanet.com/ikb/kb/articles/4905.html The knowledgebase url itself: http://knowledgebase.iplanet.com/NASApp/ikb/index.jsp This site may lead you to some useful info: http://developer.iplanet.com/ Also, a perl +nsapi search on http://devedge.netscape.com/ could be useful. g'luck /dennis __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
[ANNOUNCE] Apache::ASP v2.45 released
Hey,
Apache::ASP v2.45 is released to CPAN. This is a fairly large
release with some new features, performance enhancements bug fixes.
Please see the change log below.
For more information about Apache::ASP, please see the web site at:
http://www.apache-asp.org
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
CHANGES for 2.45
++New XMLSubsPerlArgs config, default 1, indicates how
XMLSubs arguments have always been parsed. If set to 0,
will enable new XMLSubs args that are more ASP like with
%= % for dynamic interpolation, such as:
my:xmlsub arg=%= $data % arg2=text %= $data2 % /
Settings XMLSubsPerlArgs to 0 is experimental for now, but
will become the default by Apache::ASP version 3.0
++Optimization for static HTML/XML files that are served up
via Apache::ASP so that they are not compiled into perl subroutines
first. This makes especially native XSLT both faster take
less memory to serve, before XSL XML files being transformed
by XSLT would both be compiled as normal ASP script first, so
now this will happen if they really are ASP scripts with embedded
% % code blocks XMLSubs being executed.
+Consolidate some config data for Apache::ASP-Loader to use
globals in Apache::ASP::CompileChecksumKeys to know which
config data is important for precompiling ASP scripts.
+Further streamlined code compilation. Now both base
scripts and includes use the internal CompileInclude() API
to generate code.
-Fixed runtime HTML error output when Debug is set to -2/2,
so that script correctly again gets rendered in final perl form.
Added compile time error output to ./site/eg/syntax_error.htm
when a special link is clicked for a quick visual test.
-Cleaned up some bad coding practices in ./site/eg/global.asa
associated changes in other example files. Comment example
global.asa some for the first time reader
-DemoASP.pm examples module needed use strict fix, thanks
to Allan Vest for bug report
--$rv = $Response-Include({ File = ..., Cache = 1});
now works to get the first returned value fetched from
the cache. Before, because a list was always returned,
$rv would have been equal to the number of items returned,
even if the return value list has just one element.
(d) added site/robots.txt file with just a comment for
search engine indexing
-fixed ./site/eg/binary_write.htm to not use
$Response-{ContentLength} because it does not exist.
Fixed it to use $Response-AddHeader now instead
Re: Segfaults when using XML::Parser
I have found this section under the Warnings and Errors Troubleshooting on the web site. It states: If you have some of the processes segfault when using XML::Parser you should use --disable-rule=EXPAT during the Apache configuration step. Starting from mod_perl version 1.23 this option is disabled by default. It is unclear to me where this disable-rule is specified. I would assume in apache, but then it makes a statement that the option has been disabled by default for mod_perl 1.23+. That seems to imply the option is in mod_perl? Can someone please give me specific information about how I would go about using this disable-rule to fix the afformentioned problem. Can someone also give me some information on why this is needed to fix the problem...what is the root cause of this problem? I have only ran into this problem on my fully updated RedHat 7.3 box (apache 1.3.23 mod_perl 1.26), not my RH 6.2 (apache 1.3.12 mod_perl 1.24) boxes. Please advise. - David Castro Software Architect Collaborative Technologies Information Media Technology Azusa Pacific University My little children, let us not love in word or in tongue, but in deed and in truth. -- 1 Jn 3:18 (NKJ)
Trouble Compiling Mod_Perl 1.27 on SGI
Greetings, Having trouble building mod_perl-1.27 against Apache_1.3.27 on an SGI Gettting: Will run tests as User: 'webuser' Group: 'webgroup' (cd ../apache_1.3.27 CC=cc -n32 CFLAGS= -D_BSD_TYPES -D_BSD_TIME -woff 1184 1552 -OPT:Olimit=0:space=ON -I/usr/local/include -DLANGUAGE_C ./configure --activate-module=src/modules/perl/libperl.a --disable-rule=EXPAT --prefix=/users/webuser/apache_heavy) Configuring for Apache, Version 1.3.27 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src You are running 64-bit Irix. For now, we will compile 32-bit but if you would care to port to 64-bit, send us the patches. + configured for SGI IRIX-64 platform + setting C pre-processor to cc -n32 -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + id: mod_perl/1.27 + id: Perl/v5.8.0 (irix) [perl] + setting up mod_perl build environment + adjusting Apache build environment + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; cc -n32 -DIRIX -DMOD_PERL -DUSE_HSREGEX -DNO_DL_NEEDED -D_BSD_TYPES -D_BSD_TIME -woff 1184 1552 -OPT:Olimit=0:space=ON -I/usr/local/include -DLANGUAGE_C `./apaci` -o helpers/dummy helpers/dummy.c -L/usr/local/lib32 -L/usr/local/lib -Wl,-woff,84 /users/webuser/perl/lib/5.8.0/IP25-irix/auto/DynaLoader/DynaLoader.a -L/users/webuser/perl/lib/5.8.0/IP25-irix/CORE -lperl -lm -lc ld32: FATAL 9: I/O error (1552): No such file or directory *** Error code 2 (bu21) = End of Error Report = Tried it on several different SGI boxes with the same result. Any suggestions would be appreciated. Thank You, John Kent Monterey, CA
Apache::Clean mod_perl 2.0 port
hi all... I had a few moments so I've started to port Apache::Clean over to mod_perl 2.0. it's far from complete, and I haven't examined all the issues with proper caching headers yet, but you can find the work in progress here: http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-Clean-2.00b.tar.gz it's _very_ alpha, so if you have problems, well, consider it an invitation to polish your debugging skills :) I'll be playing with it on and off, though, so feel free to contact me directly about it. the only real issue I noticed is that the 1.3 Apache::Filter and mod_perl 2.0 Apache::Filter don't seem to play nice with PerlModule Apache2, but it could have been something in my setup. I ended up needing to uninstall Ken's old Apache::Filter to make the test suite work. anyway, as I said it's a work in progress, but for those of you who want to play around with the 2.0 API and haven't yet (like me) Apache::Clean is itself a PerlOutputFilterHandler, and the distribution includes a (brief) example of SetHandler modperl and the Apache::Test test suite. have fun. --Geoff
Re: Segfaults when using XML::Parser
DavidIf you have some of the processes segfault when using DavidXML::Parser you should use David--disable-rule=EXPAT Davidduring the Apache configuration step. David DavidStarting from mod_perl version 1.23 this option is Daviddisabled by default. David It is unclear to me where this disable-rule is specified. In the configure line for Apache, like so: ./configure --disable-rule=EXPAT \ --activate-module=src/modules/perl/libperl.a David I would assume in apache, but then it makes a statement that David the option has been disabled by default for mod_perl 1.23+. David That seems to imply the option is in mod_perl? That's assuming you have the mod_perl distribution build Apache for you, not if you're doing it the other way around. David Can someone please give me specific information about how I David would go about using this disable-rule to fix the David afformentioned problem. The above should help. David Can someone also give me some information on why this is David needed to fix the problem...what is the root cause of this David problem? I have only ran into this problem on my fully David updated RedHat 7.3 box (apache 1.3.23 mod_perl 1.26), not David my RH 6.2 (apache 1.3.12 mod_perl 1.24) boxes. Please David advise. XML::Parser doesn't hide it's symbols properly and hence they collide with the expat-lite that's in Apache by default. I can't believe this hasn't been fixed by now. Nonetheless, this subject has been covered over and over on the list. If you look in the archives you'll most certainly find more details. b. -- /* Bruno Connelly, [EMAIL PROTECTED] */
Re: Segfaults when using XML::Parser
Thanks. I found that I was using a custom apache build without that enabled, but it is fixed now with a newer apache RPM for redhat. Thanks again. On Mon, 14 Oct 2002, Bruno Connelly wrote: David If you have some of the processes segfault when using David XML::Parser you should use David --disable-rule=EXPAT David during the Apache configuration step. David David Starting from mod_perl version 1.23 this option is David disabled by default. David It is unclear to me where this disable-rule is specified. In the configure line for Apache, like so: ./configure --disable-rule=EXPAT \ --activate-module=src/modules/perl/libperl.a David I would assume in apache, but then it makes a statement that David the option has been disabled by default for mod_perl 1.23+. David That seems to imply the option is in mod_perl? That's assuming you have the mod_perl distribution build Apache for you, not if you're doing it the other way around. David Can someone please give me specific information about how I David would go about using this disable-rule to fix the David afformentioned problem. The above should help. David Can someone also give me some information on why this is David needed to fix the problem...what is the root cause of this David problem? I have only ran into this problem on my fully David updated RedHat 7.3 box (apache 1.3.23 mod_perl 1.26), not David my RH 6.2 (apache 1.3.12 mod_perl 1.24) boxes. Please David advise. XML::Parser doesn't hide it's symbols properly and hence they collide with the expat-lite that's in Apache by default. I can't believe this hasn't been fixed by now. Nonetheless, this subject has been covered over and over on the list. If you look in the archives you'll most certainly find more details. b. -- /* Bruno Connelly, [EMAIL PROTECTED] */ - David Castro Software Architect Collaborative Technologies Information Media Technology Azusa Pacific University My little children, let us not love in word or in tongue, but in deed and in truth. -- 1 Jn 3:18 (NKJ)
Re: Apache Hello World Benchmarks Updated
Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. - Perrin
Re: Apache Hello World Benchmarks Updated
On Tue, 15 Oct 2002, Perrin Harkins wrote: Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of 1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and 1.11 had that leak plus another, much nastier one. Also FWIW, running Joshua's tests on my machine uniformly used about 1/3 to 1/4 as much RAM, with Mason, Template Toolkit and Apache::ASP. I too am running GNU/Linux, with a 2.4 kernel, on i386 hardware. The only difference in software was that I have Perl 5.8.0 installed, but I'd be incredibly shocked if that explained the difference. I've used Mason on a lot of machines, and I've found that processed between 15-30MB (with mod_perl are relatively normal. While this isn't tiny, it isn't nearly as bad as the 60MB monster Josh found. I'm actually pretty comfortable with Mason's memory usage because I think that certain features it offers explain its memory use. Basically, any framework that offers filtering features on generated output will need to store the entire output in memory before sending it, and I suspect this is one thing I think has a big impact on Mason's memory usage. -dave /*== www.urth.org we await the New Sun ==*/
Re: Apache Hello World Benchmarks Updated
Perrin Harkins wrote: Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of For the purposes of the benchmark, using Apache::SizeLimit won't do much the worst results are only showing 3M unshared per process 8M total memory per process. The benchmarks run at 20 MaxClients. MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? For Embperl 2.x it made a world of difference on the memory side, with only a slight performance impact of 5-10%, but reduced memory usage from 60M to 25M for the test. Gerald I have found real memory leaks in Embperl 2.x, where this kind of config is necessary. Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks Right... I looked into HTML::Mason today, and agree with you and David that for HTML::Mason there is not a memory leak, it just uses more unshared memory than other environments at runtime, and the MaxRequestsPerChild did not seem to make a difference. This might also be true of Template Toolkit. I'll look into the latter more. I just assumed if the unshared memory footprint was as high as it was for these environments, that there must have been a leak like in Embperl 2.x. I also looked into AxKit which seems to use more memory, but it too does not seem to have a leak. implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. Right. What I go for in the benchmarks as far as a memory leak goes is do the environments seem to use the same amount of memory at 30 seconds as they do at 60 seconds. In the case of Embperl 2.x, this was very different, but in the case of HTML::Mason, it stays the same. Thanks as always for your feedback. --Josh
Re: Apache Hello World Benchmarks Updated
Dave Rolsky wrote: I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of 1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and 1.11 had that leak plus another, much nastier one. Yes, Mason seemed pretty free of leaks when I tested it more today too. Also FWIW, running Joshua's tests on my machine uniformly used about 1/3 to 1/4 as much RAM, with Mason, Template Toolkit and Apache::ASP. I too am running GNU/Linux, with a 2.4 kernel, on i386 hardware. The only difference in software was that I have Perl 5.8.0 installed, but I'd be incredibly shocked if that explained the difference. This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. I'm actually pretty comfortable with Mason's memory usage because I think that certain features it offers explain its memory use. Basically, any framework that offers filtering features on generated output will need to store the entire output in memory before sending it, and I suspect this is one thing I think has a big impact on Mason's memory usage. Yep, especially with how perl can store internal data structures relatively inefficiently, where 20K of data represented internally can easily bloat up to 100K internally depending on how its being stored, and matters are probably made worse by code data being intermingled so dirtying the data dirties the code pages to to become unshared. I think that is how Gerald achieves his low memory footprints generally in Embperl, since he is doing most of his stuff in C it seems, and still offering all the advanced features we have in the other application frameworks. Regards, Josh
Re: Apache Hello World Benchmarks Updated
On Mon, 14 Oct 2002, Josh Chamas wrote: This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. I ran the Mason 2000 test for 60 seconds and it only used about 20MB. I think that is how Gerald achieves his low memory footprints generally in Embperl, since he is doing most of his stuff in C it seems, and still offering all the advanced features we have in the other application frameworks. It might be worth trying to implement a few parts of Mason in C, particularly the Buffer class, though I'm not really sure I'm the one to do it, given my weak (and without honor) C skills. -dave /*== www.urth.org we await the New Sun ==*/
Re: Apache Hello World Benchmarks Updated
Hi,
(as far as i can tell after a quick peek at the code and some debugging)
It looks like there is a bug w/ AxKit::run_axkit_engine() and/or
Apache::AxKit::Cache::_get_stats()
run_axkit_engine() wants to create a .gzip cachefile when AxGzipOutput is off.
When AxGzipOutput is off the .gzip file is never made and _get_stats()
returns w/ !$self-{file_exists} effectivly disabling delivering cached copies.
With AxGzipOutput enabled both files are created and appropriate cached copies
are delivered as expected.
I haven't decided for myself a best fix except for just enabling AxGzipOutput.
So, I reran hello/bench.pl w/ AxGzipOutput On and sped axkit up quite a bit.
attached are some diffs and a couple of 1 sec bench.pl runs. Would be
interesting to see how axkit compares now?
Thanks,
Ed
On Mon, Oct 14, 2002 at 12:26:06AM -0700, Josh Chamas wrote:
Hey,
The Apache Hello World benchmarks are updated at
http://chamas.com/bench/
The changes that affect performance numbers include:
Set MaxRequestsPerChild to 1000 globally for more realistic run.
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
This is a more typical setting in a mod_perl type application that
leaks memory, so should be fairly representative benchmark setting.
Note that the latter change seemed to have the most benefit for Embperl 2.0,
with some benefit for Template Toolkit less ( but some ) for HTML::Mason
on the memory usage numbers.
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
--- hello/bench.pl Sun Oct 13 04:07:35 2002
+++ hello-gz/bench.pl Tue Oct 15 00:15:48 2002
-106,7 +106,7
# FIND AB
my $httpd_dir = $HTTPD_DIR;
-$AB = $httpd_dir/ab;
+$AB = '/usr/sbin/ab'; #$httpd_dir/ab;
unless(-x $AB) {
print ab benchmark utility not found at $AB, using 'ab' in PATH\n;
$AB = 'ab';
--- hello/bench.pl Sun Oct 13 04:07:35 2002
+++ hello-gz/bench-gz.plTue Oct 15 00:16:32 2002
-106,7 +106,7
# FIND AB
my $httpd_dir = $HTTPD_DIR;
-$AB = $httpd_dir/ab;
+$AB = '/usr/sbin/ab'; #$httpd_dir/ab;
unless(-x $AB) {
print ab benchmark utility not found at $AB, using 'ab' in PATH\n;
$AB = 'ab';
-583,6 +583,7
AxAddStyleMap application/x-xpathscript
+Apache::AxKit::Language::XPathScript
AxAddProcessor text/xsl hello.xsl
AxCacheDir $TMP/axkit
+ AxGzipOutput On
}],
'AxKit XSLT Big' = ['hxsltbig.xml', qq{
-593,6 +594,7
AxAddStyleMap application/x-xpathscript
+Apache::AxKit::Language::XPathScript
AxAddProcessor text/xsl hxsltbig.xsl
AxCacheDir $TMP/axkit
+ AxGzipOutput On
}],
'AxKit XSP Hello' = ['hello.xsp', qq{
-601,6 +603,7
AxAddStyleMap application/x-xsp +Apache::AxKit::Language::XSP
AxAddProcessor application/x-xsp NULL
AxCacheDir $TMP/axkit
+ AxGzipOutput On
}],
'AxKit XSP 2000' = ['h2000.xsp', qq{
-609,6 +612,7
AxAddStyleMap application/x-xsp +Apache::AxKit::Language::XSP
AxAddProcessor application/x-xsp NULL
AxCacheDir $TMP/axkit
+ AxGzipOutput On
}],
# new Embperl 2.x series
[2002-10-15 00:16:53] Found apache web server at /usr/local/sbin/httpd_perl
[2002-10-15 00:16:53] running 1 groups of benchmarks for 1 seconds
[2002-10-15 00:16:56] testing AxKit v1.6 XSP 2000 at
http://localhost:5000/h2000.xsp?title=Hello%20World%202000integer=2000
[2002-10-15 00:17:11] testing AxKit v1.6 XSP Hello at http://localhost:5000/hello.xsp
[2002-10-15 00:17:25] testing AxKit v1.6 XSLT Hello at http://localhost:5000/hxslt.xml
[2002-10-15 00:17:40] testing AxKit v1.6 XSLT Big at http://localhost:5000/hxsltbig.xml
Test Name Test File Hits/sec # of Hits Time(sec)
secs/Hit Bytes/Hit
- - - - -
- -
AxKit v1.6 XSP 2000 h2000.xsp14.8 20 1.35
0.067600 28680
AxKit v1.6 XSP Hellohello.xsp 245.5261 1.06
0.004073 353
AxKit v1.6 XSLT Hello hxslt.xml 157.6169 1.07
0.006343 331
AxKit v1.6 XSLT Big hxsltbig.x 37.3 38 1.02
0.026816 21590
Apache Server Header Tokens
---
Apache/1.3.26
AxKit/1.6
mod_perl/1.27
PERL Versions: 5.006001
[2002-10-15 00:18:04] Found apache web server at /usr/local/sbin/httpd_perl
[2002-10-15 00:18:04] running 1 groups of benchmarks for 1 seconds
[2002-10-15 00:18:07] testing AxKit v1.6 XSP 2000 at
