Re: Apache dies when configure mod_perl for use with Apache::DBI
Richard Clarke wrote: PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric. Sorry about the typo, but I've tried it with the 'use' also. The 'startup.pl' that is in the link above to which you refer gives the same result too. Feite -- _BR PRE Osiris-IT Bovenweg 34 8422 DH Nijeberkoop Tel.: 0516-441540 e-mail : [EMAIL PROTECTED] website : A HREF=http://www.osiris-it.nl;http://www.osiris-it.nl/A /PRE
Re: Apache dies when configure mod_perl for use with Apache::DBI
Feite Brekeveld wrote: Richard Clarke wrote: PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric. Sorry about the typo, but I've tried it with the 'use' also. The 'startup.pl' that is in the link above to which you refer gives the same result too. make sure that you are using the latest DBI and Apache::DBI __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache dies when configure mod_perl for use with Apache::DBI
As soon as I activate the line identified as 'trouble line', my apache server dies. Can you elaborate on this.. how does it die?, what is the error msg? etc.. (That is assuming it's still a problem after upgrading to latest DBI/Apache::DBI as Stas suggested). Ric.
Re: Apache dies when configure mod_perl for use with Apache::DBI
Richard Clarke wrote: As soon as I activate the line identified as 'trouble line', my apache server dies. Can you elaborate on this.. how does it die?, what is the error msg? etc.. (That is assuming it's still a problem after upgrading to latest DBI/Apache::DBI as Stas suggested). Ric. This is the only error line that appears in the error_log. [Sun Mar 2 20:10:19 2003] [notice] caught SIGTERM, shutting down As Stas suggested I downloaded the latest versions of DBI and Apache::DBI, and still got the error. But this time it was Apache::Status which was before Apache::DBI in the startup file. At the moment of posting I hadn't included Apache::Status so probably the minor version differences were the problem. Thanks for the support. Feite
RE: Apache dies when configure mod_perl for use with Apache::DBI
This is the only error line that appears in the error_log. [Sun Mar 2 20:10:19 2003] [notice] caught SIGTERM, shutting down Perhaps it's me, but could you please create a copy-n-paste mail with the (correct) relevant code snippets (httpd.conf, startup.pl, etc.). This might help. Best regards, Frank
Apache dies when configure mod_perl for use with Apache::DBI
Hi,
I'm trying to configure mod_perl for use with persistent database
connections with Apache::DBI
RedHat 7.3
Apache 1.3.23
mod_perl 1.26
I've configured the following 'startup.pl' file:
-
#!/usr/bin/perl
BEGIN {
use Apache ();
use lib '/etc/httpd/lib/perl';
}
use Apache::Registry ();
use Apache::Constants();
use CGI qw(-compile :all);
use CGI::Carp ();
#
PerlModule Apache::DBI;-- trouble line
#use LWP ();
#
1;
---
As soon as I activate the line identified as 'trouble line', my apache
server dies.
Any suggestions ?
Thanks,
Feite Brekeveld
Re: Apache dies when configure mod_perl for use with Apache::DBI
PerlModule Apache::DBI;-- trouble line This line belongs in your httpd.conf file. PerlModule is an apache configuration directive, not a perl 'command'. http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire _Directives Ric.
Re: make test failed when installing mod_perl 2.0 on Linux
Your attention please: [***] [*** ***] [*** please send the followups back to the list! ***] [*** ***] [***] Thank you! Now to the solutions: Dawn Sun wrote: I've used this patch Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 26 Nov 2002 12:20:03 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Good, so probably adding PerlModule TestHook::trans in a similar way (inside Base/Base of t/hooks/TestHooks/trans.pm) should solve that problem too. Though it should have resolved the handlers automatically. You need to enable PERL_TRACE (see the online docs) and post the trace so we can see why these don't get resolved. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
make test failed when installing mod_perl 2.0 on Linux
Hi I am new to linux and mod_perl. Weare runningperl 5.8.0 and apache 2.0.43 on linux.First time we are tryingtoinstall mod_perl2.But the "make test"failed completed. Here is the error_log reads: END in modperl_extra.pl, pid=19385[Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0configured -- resuming normal operations[Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20[Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem)[Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first'[Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pmin @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first'[Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo'[Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter'[Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387)[Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting downEND in modperl_extra.pl, pid=19387 I've checked the actual module in @INC. It does exist. Then I'vesearched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.htmlsuggested. But "make test" failed again. This time, the error changed from the "Can't locate TestHooks/init/first.pm in @INC... " to "Can't locate TestHooks/trans.pm in @INC...". Other errors remain the same. Any suggestions? Dawn
Re: make test failed when installing mod_perl 2.0 on Linux
please remember to properly report problems, as explained at: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (hint: the shortcuts menu on the left side of any page of perl.apache.org) if you don't provide all the required details it makes it hard to guess what configuration you've the problem with. I had this problem a while ago with the worker mpm over 5.8.0: http://marc.theaimsgroup.com/?l=apache-modperl-devm=101128927611980w=2 but I think it should be OK now. I am new to linux and mod_perl. We are running perl 5.8.0 and apache 2.0.43 on linux. First time we are trying to install mod_perl2. But the make test failed completed. Here is the error_log reads: END in modperl_extra.pl, pid=19385 [Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 configured -- resuming normal operations [Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20 [Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter' [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387) [Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=19387 I've checked the actual module in @INC. It does exist. Then I've searched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.html suggested. But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Any suggestions? Dawn -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Error when making mod_perl
Hi there, On Thu, 19 Sep 2002, Christophe Mailhe wrote: [snip] * WARNING * mod_perl is unlikely to link with your libperl, suggestions: *) Rebuild Perl with Configure -Accflags=+Z ... [snip] Are you sure you're trying to link to the Perl that you just built? You didn't tell us quite a lot of things (for example what mod_perl version:). Have a look at the file called SUPPORT in the mod_perl directory, it tells you the sort of things to post which might be helpful to the people here. Have you tried Perl 5.6? Or even 5.005_03? I need this module working ASAP. Now where have I heard that before? :) 73, Ged.
RE: Error when making mod_perl
Hi there, Sorry I didn't give all the information. I think I have achieved to compile perl 5.8.0 and now mod_perl-1.99_05 using the following commands : For Perl 5.8.0: Configure -d -e -Dcc=gcc -Dprefix=/usr/local -Duseshrplib useposix=true -A append:ccflags=' -fPIC' make make test make install For ModPerl: /usr/local/bin/perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 make make test make install ModPerl is now installed, but I am not able to start apache. (apache v 2.0.4). When using apachectl start, this is starting /usr/local/apache2/bin/httpd -k start TTY PID USERNAME PRI NI SIZERES STATETIME %WCPU %CPU COMMAND pts/tb 2821 root 225 20 868K 924K run 8:04 95.01 94.84 httpd After 20 minutes this is still hanging and httpd is not started! This is a cut of my httpd.conf : ... LoadModule actions_module modules/mod_actions.so LoadModule speling_module modules/mod_speling.so LoadModule userdir_module modules/mod_userdir.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule perl_module modules/mod_perl.so PerlModule Apache2 PerlSwitches -w # # ExtendedStatus controls whether Apache will generate full status # information (ExtendedStatus On) or just basic information (ExtendedStatus # Off) when the server-status handler is called. The default is Off. # ExtendedStatus On ### Section 2: 'Main' server configuration ... Chris. Oh, Ged, by the way, I didn't find the SUPPORT file you were speaking about. Can someone send me that? Cheers. -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 10:22 AM To: Christophe Mailhe Cc: '[EMAIL PROTECTED]' Subject: Re: Error when making mod_perl Hi there, On Thu, 19 Sep 2002, Christophe Mailhe wrote: [snip] * WARNING * mod_perl is unlikely to link with your libperl, suggestions: *) Rebuild Perl with Configure -Accflags=+Z ... [snip] Are you sure you're trying to link to the Perl that you just built? You didn't tell us quite a lot of things (for example what mod_perl version:). Have a look at the file called SUPPORT in the mod_perl directory, it tells you the sort of things to post which might be helpful to the people here. Have you tried Perl 5.6? Or even 5.005_03? I need this module working ASAP. Now where have I heard that before? :) 73, Ged. Information may be contained in this message which is legally privileged and/or confidential. If you are not the addressee(s) legally indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my employer unless otherwise indicated by an authorised representative independent of this message. Please note that neither my employer nor I accept any responsibility for viruses and it is your responsibility to scan attachments (if any). If you have received this transmission in error it would be helpful if you could notify us as soon as possible.
RE: Error when making mod_perl
Hello again, On Fri, 20 Sep 2002, Christophe Mailhe wrote: Hi there, Sorry I didn't give all the information. I think I have achieved to compile perl 5.8.0 and now mod_perl-1.99_05 using the following commands : For Perl 5.8.0: Is this 5.8.0-RC2 (See mod_perl-1.99_05/README)? I don't yet use mod_perl versionn 2.x seriously, so there are people on this List to who are better placed than I am to answer your questions. Oh, Ged, by the way, I didn't find the SUPPORT file you were speaking about. I thought you were using mod_perl 1.x. For 2.x (1.99_05 is 2.x really, don't ask me why...:) you need to see mod_perl-1.99_05/docs/help/help.pod. 73, Ged.
Error when making mod_perl
Hi, I have a Warning when creating the Makefile from Makefile.pm : * WARNING * mod_perl is unlikely to link with your libperl, suggestions: *) Rebuild Perl with Configure -Accflags=+Z ... * WARNING * And then, I have an error message when I make mod_perl : /usr/bin/ld -b -L/usr/local/lib \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_ca llback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl _pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modp erl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo -E -B deferred -L/usr/local/lib /usr/local/lib/perl5/5.8.0/P A-RISC1.1/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.8.0/PA-RISC1.1/CORE -lperl -lnsl -lnm - lmalloc -ldld -lm -lc -lndir - lcrypt -lsec \ -o mod_perl.so /usr/bin/ld: DP relative code in file al/lib/perl5/5.8.0/PA-RISC1.1/auto/DynaLoader/DynaLoader.a (DynaLoader.o) - shared libra ry must be position independent. Use +z or +Z to recompile. *** Error exit code 1 Stop. *** Error exit code 1 Stop. The thing is I have built perl 5.8.0 from source, using the following command : Configure -d -e -Dcc=gcc -Dprefix=/usr/local useposix=true - Accflags=+Z Can someone help me here. I need this module working ASAP. Many thanks, Chris. Information may be contained in this message which is legally privileged and/or confidential. If you are not the addressee(s) legally indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my employer unless otherwise indicated by an authorised representative independent of this message. Please note that neither my employer nor I accept any responsibility for viruses and it is your responsibility to scan attachments (if any). If you have received this transmission in error it would be helpful if you could notify us as soon as possible.
Make test failure when installing mod_perl 2.0 on Solaris 8 with Apache 2
Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: ./configure --enable-layout=Solaris --enable-perl=shared --with-mpm=prefork (as normal user) make(as normal user) make test (as root user) make install (as root user) this seems to install fine. I have then configured mod_perl as follows: perl Makefile.PL MP_AP_PREFIX=/usr/apache MP_INST_APACHE2=1 (as normal user) make (as normal user) make test (as root user) And the 'make test' fails: Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cgihandler.t22 100.00% 1-2 apache/compat.t33 100.00% 1-3 apache/post.t 21 50.00% 2 apache/read.t 11 100.00% 1 apache/scanhdrs.t 29 7424 44 100.00% 1-4 api/send_fd.t 32 66.67% 2-3 api/sendfile.t 32 66.67% 2-3 directive/perlmodule.t 11 100.00% 1 directive/perlrequire.t11 100.00% 1 directive/setupenv.t 31 33.33% 2 filter/input_body.t22 100.00% 1-2 filter/lc.t11 100.00% 1 hooks/access.t 42 50.00% 2-3 hooks/trans.t 33 100.00% 1-3 modperl/getc.t 21 50.00% 2 modperl/readline.t 21 50.00% 2 modperl/sameinterp.t 29 742412 12 100.00% 1-12 modules/include.t 65 83.33% 1 3-6 protocol/echo.t 255 65280 32 66.67% 2-3 protocol/echo_filter.t 255 65280 32 66.67% 2-3 50 tests skipped. So, as you can see not very good. After looking at the recommended log file (t/logs/errorlog) I see the following: bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/home/software/apache _download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/lib/Apach e2 /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apache2 /export/home/software/apache_download_2_0_39/mod_perl -1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/software/apache_down load_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/p rotocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/perlmodule-vh /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/main /usr/local/lib/perl5/5.8.0/sun4-so laris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr /local/lib/perl5/site_perl) at (eval 15) line 3. [Tue Aug 20 15:01:20 2002] [error] failed to resolve handler `TestHooks::init::first' [Tue Aug 20 15:01:20 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/li b/Apache2 /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apac he2 /export/home/software/apache_downl oad_2_0_39/mod_perl-1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/ arch /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/protocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apach e_download_2_0_39/mod_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irec
Re: Make test failure when installing mod_perl 2.0 on Solaris 8 withApache 2
Tom Hibbert wrote: Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: [...] bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in Try this patch: Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 20 Aug 2002 15:31:18 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Possible naming error when extracting mod_perl 2 tarball
Hi, I downloaded the mod-perl 2.0 tarball today from: http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz When I untar'd it: bash-2.03$ tar xf mod_perl-2.0-current.tar It extracted to the following directory: drwxr-x--- 13 software software 512 Jun 21 23:40 mod_perl-1.99_04 I was just wondering if this was correct (i.e mod_perl 2.0 extracting to mod_perl 1.99 directory). After looking at the files it looks like it is mod_perl 2 and therefore just a naming error in the archive - a minor issue, but I thought I would ask. Cheers, Tom
Re: Possible naming error when extracting mod_perl 2 tarball
Tom Hibbert wrote: Hi, I downloaded the mod-perl 2.0 tarball today from: http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz When I untar'd it: bash-2.03$ tar xf mod_perl-2.0-current.tar It extracted to the following directory: drwxr-x--- 13 software software 512 Jun 21 23:40 mod_perl-1.99_04 I was just wondering if this was correct (i.e mod_perl 2.0 extracting to mod_perl 1.99 directory). After looking at the files it looks like it is mod_perl 2 and therefore just a naming error in the archive - a minor issue, but I thought I would ask. That's correct. It'll become mod_perl-2.0.xx when the first production version is released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: when to mod_perl?
At 9:52 Uhr +0200 25.06.2002, Alessandro Forghieri wrote: FastCGI has slightly better speed, but I have seen it hanging (and it does not look like support for FastCGI is going to be huge in the futuer), It took mod_perl ages (i.e. until mod_accel has come up) to get an as decent proxying setup as mod_fastcgi has already provided right from the beginning ;) Re hanging: I've seen it too about 2 years ago with dynamic fastcgi, but that bug had then been fixed, maybe you're talking about the same (and static fastcgi has never given me problems). Christian. -- Christian Jaeger +41 1 430 45 26 http://www.eile.ethz.ch - waiting for someone to take over (and off :)
Re: when to mod_perl?
md wrote: I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. Static content is easy; just don't serve it from mod_perl. The proxy approach is good, and so is a separate image server (which you can host on the same machine). I've found thttpd to be an amazingly efficient server for images, but a slimmed-down apache does very well too. - Perrin
Re: when to mod_perl?
Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Static content is easy; just don't serve it from mod_perl. The proxy Perrin approach is good, and so is a separate image server (which you can Perrin host on the same machine). I've found thttpd to be an amazingly Perrin efficient server for images, but a slimmed-down apache does very well Perrin too. On the new www.stonehenge.com, I'm using a stripped down Apache (just mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about 1.5M RSS per process. I divert requests for TT's /splash/images and Apache's /icons, but otherwise, all content requests (including for /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, which are running about 10M RSS. Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. On a 500Mhz 256M box, I'm easily serving 50K requests a day (about 10K of those are fully uncached dynamic pages touching about 20 to 50 TT includes), with loadaverages staying below 0.5. If it ever starts getting higher, I can cache the expensive menubar creation (which is nearly completely static) using Perrin's device, but I've not bothered yet. It's been amazingly carefree. I'm planning to move www.geekcruises.com to be served on the same box, although they get only about 1/10th the traffic. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: when to mod_perl?
Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. . I have a question regarding to the cached files. Although the maximal period is set to be 24 hours in httpd.conf's proxy settings, many of the files, which were cached from the backend mod_perl dynamical program, are strangely modified every a few minutes. For all the files I checked so far, they do look to be modified because the hex strings on top of the files (such as 3D189FC2) are different after each modifications. Forgive me if this is off-topic: it is more likely a mod_proxy question. I searched, but could not find related information pages to read. Thanks. Peter Bi - Original Message - From: Randal L. Schwartz [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: md [EMAIL PROTECTED]; Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 8:38 AM Subject: Re: when to mod_perl? Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Static content is easy; just don't serve it from mod_perl. The proxy Perrin approach is good, and so is a separate image server (which you can Perrin host on the same machine). I've found thttpd to be an amazingly Perrin efficient server for images, but a slimmed-down apache does very well Perrin too. On the new www.stonehenge.com, I'm using a stripped down Apache (just mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about 1.5M RSS per process. I divert requests for TT's /splash/images and Apache's /icons, but otherwise, all content requests (including for /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, which are running about 10M RSS. Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. On a 500Mhz 256M box, I'm easily serving 50K requests a day (about 10K of those are fully uncached dynamic pages touching about 20 to 50 TT includes), with loadaverages staying below 0.5. If it ever starts getting higher, I can cache the expensive menubar creation (which is nearly completely static) using Perrin's device, but I've not bothered yet. It's been amazingly carefree. I'm planning to move www.geekcruises.com to be served on the same box, although they get only about 1/10th the traffic. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: when to mod_perl?
Peter == Peter Bi [EMAIL PROTECTED] writes: Peter I have a question regarding to the cached files. Although the Peter maximal period is set to be 24 hours in httpd.conf's proxy Peter settings, many of the files, which were cached from the backend Peter mod_perl dynamical program, are strangely modified every a few Peter minutes. For all the files I checked so far, they do look to be Peter modified because the hex strings on top of the files (such as Peter 3D189FC2) are different after each modifications. If you're talking about www.stonehenge.com, I don't provide last-modified for any of the HTML pages: they're all dynamic. If the proxy server is caching them, it's going to still punch through to the back for each hit. Similarly, if you are talking about your own site, and you *do* provide a mostly useless last modified time, then the front end is still going to go to the back end and say I've got a version from time $x, is that current? and if you're not handling if-modified-since, then every hit will be cached, uselessly. I avoid that on stonehenge by not providing last-modified for any of my HTML pages. mod_proxy thus has no idea about caching, so it's all dynamic. My images automatically have last-modified, and thus the cache can check for updates with if-modified-since, using the cache when needed. If I was really smart, I'd use mod_expires to say this image is good for $N hours, and then the front end wouldn't even touch the back end at all. As I said, as long as my loadav is low enough for my current hits, I've got better things to work on. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: when to mod_perl?
- Original Message -
From: Randal L. Schwartz [EMAIL PROTECTED]
To: Peter Bi [EMAIL PROTECTED]
Cc: Perrin Harkins [EMAIL PROTECTED]; md [EMAIL PROTECTED];
Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 10:18 AM
Subject: Re: when to mod_perl?
Peter == Peter Bi [EMAIL PROTECTED] writes:
Peter I have a question regarding to the cached files. Although the
Peter maximal period is set to be 24 hours in httpd.conf's proxy
Peter settings, many of the files, which were cached from the backend
Peter mod_perl dynamical program, are strangely modified every a few
Peter minutes. For all the files I checked so far, they do look to be
Peter modified because the hex strings on top of the files (such as
Peter 3D189FC2) are different after each modifications.
If you're talking about www.stonehenge.com, I don't provide
last-modified for any of the HTML pages: they're all dynamic. If the
proxy server is caching them, it's going to still punch through to the
back for each hit.
That is one of our sites.
Similarly, if you are talking about your own site, and you *do*
provide a mostly useless last modified time, then the front end is
still going to go to the back end and say I've got a version from
time $x, is that current? and if you're not handling
if-modified-since, then every hit will be cached, uselessly.
I used:
$r-update_mtime($id); # id is less than the current time and does not
change for a specific page
$r-set_last_modified;
if ($r-protocol =~ /(\d\.\d)/ $1 = 1.1){
$r-header_out('Cache-Control' = max-age= . 100*24*3600);
} else {
$r-header_out('Expires' = HTTP::Date::time2str($id + 100*24*3600));
}
It would not be surprising if none of the dynamic pages created was cached,
which then meant I had improper headers in mod_perl. In fact, they do serve
a number of views (maybe several tens) before modifying in the proxy
directory again. For example, I checked a file status:
$last access time: Tue Jun 25 11:44:12 2002
$last modify time: Tue Jun 25 11:40:52 2002
and for the same file later:
$last access time: Tue Jun 25 11:51:14 2002
$last modify time: Tue Jun 25 11:44:54 2002
so they were modified but not for every hits.
I avoid that on stonehenge by not providing last-modified for any of
my HTML pages. mod_proxy thus has no idea about caching, so it's all
dynamic. My images automatically have last-modified, and thus the
cache can check for updates with if-modified-since, using the cache
when needed. If I was really smart, I'd use mod_expires to say this
image is good for $N hours, and then the front end wouldn't even
touch the back end at all.
But if one makes a proper header, the proxy would not distinquish whether it
is static or dynamic. It should deliver or cache all the backend pages the
same way, providing the headers are right.
Here is another strange clue for me. The cached files have three extra
request headers X-Forwarded-For:, X-Host: , X-Server-Hostname: (from
mod_proxy_forward). While the files are modified continuously, the
X-Forwarded-For header, which record a browser's IP, does NOT change
although the later hits come from completely different IPs.
As I said, as long as my loadav is low enough for my current hits, I've
got better things to work on. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!
Peter Bi
RE: when to mod_perl?
You don't mention what OS you're using, but with Linux, 256mb just running httpd seems quite generous whether you're using mod_perl or not. From what I know, mod_perl is going to give you more performance on any given box. And now, I can't resist: When should you? Why, when you're in the mod of course ;) David LeBlanc Seattle, WA USA -Original Message- From: md [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 19:22 To: [EMAIL PROTECTED] Subject: when to mod_perl? Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
Quoting md [EMAIL PROTECTED]: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? You can easily build an application that uses the best of both worlds. The biggest benefit of mod_perl is speed, but you don't have to tie yourself tightly to mod_perl to get that benefit. I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. Good luck... Cees
Re: when to mod_perl?
--- Cees Hek [EMAIL PROTECTED] wrote: I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Thanks...that sounds reasonable. I doubt that all the dynamic pieces of this site would really require mod_perl. To answer another's reply, this will run on either Linux or BSD. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. Upgrading hardware once the load gets high was discussed...This would make the migration easier, as I have told the client that we may start with CGI then move to mod_perl later. I've never used Apache::Registry before, but this sounds like a good solution. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. I normally use CGI::Application, but in this case I'll also need something like CGI::Session as well, not to mention either Template-Toolkit or HTML::Template. Are there any gotchas with CGI::Session and Apache::Registry? And yes, I'll read The Guide :) Good luck... Thanks for the help! __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
md wrote: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? Don't get mislead by the memory requirements. If your code will run 10 times faster you will need *at least* 10 times less servers to do the job. But it's not uncommon to get even better speedups. So chances are that mod_perl will be a win in any case. Read the guide for restricting the memory used, shared memory, etc., and you are all set. It includes some numbers, showing how much memory you really need if you follow the guidelines. The only situation when mod_cgi could be a win over mod_perl is when you have almost zero code loaded and most of your operations are CPU or IO/bound, so mod_perl's precompilation/caching won't help much. but that's a very rare situation. In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: when to mod_perl?
--- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. Peter Bi - Original Message - From: md [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:36 PM Subject: Re: when to mod_perl? --- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
Peter Bi wrote: wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. good point, Peter. And there are many others. It's the best if you can take some time and read the guide before you start coding. It includes a big chunk of the wisdow that passed through this list in the last 5 years. In your case I'd suggest reading at least: http://perl.apache.org/release/docs/1.0/guide/strategy.html http://perl.apache.org/release/docs/1.0/guide/scenario.html http://perl.apache.org/release/docs/1.0/guide/performance.html and probably these two: http://perl.apache.org/release/docs/general/perl_reference.html http://perl.apache.org/release/docs/1.0/guide/porting.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
