Re: PerlInitHandler and PerlSetEnv
There is no directory, .htaccess in the context and that's like it really behaves. (unless they changed it in a very recent version and didn't update the docs, which I don't expect) PerlSetEnv is the only chance to have different values in different directories. i think the docs are out-of-date, seems to work inside location: Doug, you are right. It apears in the Apache CHANGES file for 1.3.7, but the docs still not updated Gerald P.S. I have made a bug report, so hopefully the docs will get updated also - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: can't start apache-1.3.20 with mod_perl and Mason
* On Tue, Jul 10, 2001 at 07:13:30PM -0700, Doug MacEachern wrote: On Mon, 9 Jul 2001, Louis-David Mitterrand wrote: After upgrading my installation to Apache-1.3.20 and mod_perl-1.25 as as a module I can't start apache anymore when httpd.conf contains: PerlRequire /etc/apache/perl/handler.pl And that file (for debugging purposes) is practically empty: #!/usr/bin/perl package HTML::Mason; use strict; use HTML::Mason; use HTML::Mason::ApacheHandler; 1; Running strace apache -X shows: read(3, ETE PATCH PROPPATCH MKCOL COPY M..., 4096) = 4096 read(3, mLog directive (see below).\n#\nLo..., 4096) = 4096 read(3, n /icons/uuencoded.gif .uu\nA..., 4096) = 4096 read(3, tweak mime.types without actual..., 4096) = 4096 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ see mod_perl-1.25/SUPPORT for hints on howto get a stacktrace. Thanks for your help. Here is the result of a gdb run: Program received signal SIGSEGV, Segmentation fault. 0x402b14b6 in Perl_sighandler () from /usr/lib/libperl.so.5.6 (gdb) bt #0 0x402b14b6 in Perl_sighandler () from /usr/lib/libperl.so.5.6 #1 0x402b1ab9 in Perl_hv_store () from /usr/lib/libperl.so.5.6 #2 0x402b172a in Perl_hv_fetch () from /usr/lib/libperl.so.5.6 #3 0x40272c14 in Perl_gv_fetchpv () from /usr/lib/libperl.so.5.6 #4 0x402707de in Perl_init_stacks () from /usr/lib/libperl.so.5.6 #5 0x4026cdee in perl_parse () from /usr/lib/libperl.so.5.6 #6 0x4026c210 in perl_parse () from /usr/lib/libperl.so.5.6 #7 0x402213f4 in perl_startup () from /usr/lib/apache/1.3/mod_perl.so #8 0x402252a9 in perl_cmd_require () from /usr/lib/apache/1.3/mod_perl.so #9 0x08054bd9 in ap_clear_module_list () #10 0x08054f5a in ap_handle_command () #11 0x08054fa1 in ap_srm_command_loop () #12 0x080554d2 in ap_process_resource_config () #13 0x08055bcc in ap_read_config () #14 0x0805d2b4 in ap_child_terminate () #15 0x0805da5d in main () #16 0x400e038b in __libc_start_main () from /lib/libc.so.6 (gdb) Will I have to build a debugging-enabled libperl to get relevant information? Or is this enough to understand the problem? -- HIPPOLYTE: Madame, avant que de partir, J'ai cru de votre sort devoir vous avertit. (Phèdre, J-B Racine, acte 2, scène 2)
Apache::Upload filehandle
I'm trying to use image magick to manipulate images that are uploaded via http. To
handle the uploaded images I'm using libapreq's Apache::Upload.
I wrote the below simple example script to help explain my problem.
When an image is uploaded to it I get this error in the apache error log:
ImageMagick error: Warning 320: no delegate for this image format
(:Upload=GLOB(0x873bcec)) [No such file or directory]
I'm confused why this happens. Could someone please explain this behaviour to me?
package UploadFile;
use Apache;
use Apache::Request;
use Apache::Constants qw(:common);
use CGI qw(-compile :standard);
use Image::Magick;
sub handler {
my $r = new Apache::Request(shift);
if ($r-param('action') eq upload) {
my $image = new Image::Magick;
my $error = $image-Read(file=$r-upload()-fh());
$r-log_error(ImageMagick error: $error) if $error;
$r-print(image geometry: . join x , $image-Get('width', 'height'));
undef $image;
}
$r-print(start_html() . start_multipart_form() . Upload an image: .
filefield(-name=uploadedfile) . submit(-name=action, -value=upload) .
end_form() . end_html());
return OK;
}
1;
Re[2]: upgrading mod_perl/CGI.pm shows some weirdness
On Wednesday, July 11, 2001, Doug MacEachern wrote the following about upgrading mod_perl/CGI.pm shows some weirdness DM On 6 Jul 2001, Peter Rooney wrote: machine 1: CGI.pm version 2.46 machine 2 (the new machine): CGI.pm version 3.02 DM 3.02 is alpha, the README says: DM Version 3 of CGI.pm is in alpha state. It has significant performance DM improvements over the 2.X series, but is not stable. If you find a DM bug, please track it down, fix it, and send me the patch. DM i would send lincoln and report and stick with the 2.xx version for DM production. FWIW, i noticed that CPAN.pm installs 3.02 when you type install CGI. That could be an issue for some people. Best Regards, Mike e-mail: [EMAIL PROTECTED]
[DIGEST] mod_perl digest 2001/07/07
-- mod_perl digest July 1, 2001 - July 7, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o cvs patches o module announcements o mailing list highlights o links mod_perl status o mod_perl - stable: 1.25 (released January 29, 2001) [1] - development: 1.25_02-dev [2] o Apache - stable: 1.3.20 (released May 15, 2001) [3] - development: 1.3.21-dev [4] o Perl - stable: 5.6.1 (released April 9, 2001) [5] - development: 5.7.1 [6] cvs patches The following patches are present in the official 1.25_01: o fix -[TB] file tests against $r-finfo [7] o fix for finding Apache::ExtUtils at build time [8] o add Apache::add_version_component() function [9] o a few additions to .def and .exp files [10] [11] o silence minor Test::Harness warning [12] o Apache::SizeLimit enhancements [13] These are in CVS: o enabled Apache::ModuleConfig and Apache::src support on win32 [14] [15] o allow per-server and per-location PerlSetEnv to be properly merged when a per-server handler is configured [16] o Apache-server will now point the current VirtualHost when inside a Perl section [17] module announcements o Big news for the week - mod_perl 1.25_01 was released [18] The Changes file is rather long - just go ahead and get it [19] o CGI::URI2param 0.03 - takes a CGI.pm or Apache::Request object and a keywords/regex map and applies the regexs to the URI, placing the results in param(). Nifty. [20] o HTML::Embperl 2.0b3 - embed Perl code in your HTML documents [21] o Module::Use 0.02 - record the modules used over the course of the Perl interpreter's lifetime [22] An offshoot of this thread from last week [23] mailing list highlights o Ah, yes, yet another template war [24] [25] [26]. At least this time we got some information on the status of ePerl [27] o Here is some advocacy stuff [28] [29] o Most of the other activity this week was related to patch activity. links o The Apache/Perl Integration Project [30] o mod_perl documentation [31] o mod_perl modules on CPAN [32] o mod_perl homepage [33] o mod_perl news and advocacy [34] o mod_perl list archives [35] [36] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.cpan.org/src/stable.tar.gz [6] http://www.cpan.org/src/devel.tar.gz [7] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99443970506568w=2 [8] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99445016008845w=2 [9] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99445164513156w=2 [10] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99444000811254w=2 [11] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99445183513696w=2 [12] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99445239015943w=2 [13] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99442711400394w=2 [14] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99469104232137w=2 [15] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99478709505951w=2 [16] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99473585009334w=2 [17] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=99482056311537w=2 [18] http://forum.swarthmore.edu/epigone/modperl/yangmarswen [19] http://perl.apache.org/dist/mod_perl-1.25_01.tar.gz [20] http://forum.swarthmore.edu/epigone/modperl/vaxkaxfleld [21] http://forum.swarthmore.edu/epigone/modperl/webrendpee [22] http://forum.swarthmore.edu/epigone/modperl/dandpreestee [23] http://forum.swarthmore.edu/epigone/modperl/brarsnendkhe [24] http://forum.swarthmore.edu/epigone/modperl/nouswinverm [25] http://forum.swarthmore.edu/epigone/modperl/zhixswahar [26] http://forum.swarthmore.edu/epigone/modperl/snorskaxsper [27] http://forum.swarthmore.edu/epigone/modperl/shusmunkan [28] http://forum.swarthmore.edu/epigone/modperl/khinsmumhan [29] http://forum.swarthmore.edu/epigone/modperl/dendnysming [30] http://perl.apache.org [31] http://perl.apache.org/#docs [32] http://www.cpan.org/modules/by-module/Apache/ [33] http://www.modperl.com [34] http://www.take23.org [35] http://forum.swarthmore.edu/epigone/modperl/ [36] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
Re: help about ap_pool in Perl
Doug MacEachern wrote: On Tue, 10 Jul 2001, Alberto Canzi wrote: Hi I need to use the ap_pool structure. In my Apache Module writing book is explained how to use it in C but nothing is said about using it in Perl. How does it work ? How may I use it in Perl? what do you need to use it for from Perl? much of the Perl api uses ap_pool underneath, and certain functions are exposed, such as register_cleanup, but normally you shouldn't need to use it directly from Perl. I need to save some status informations about each request (in my filter each request passes through 3 phases : PerlTransHandler, PerlAccessHandler and PerlHandler. I do something at each phase and I need to save somewhere the status. Now I use $r-connection-user that is persistent from the Translation phase to Handler phase ... It isn't very nice, but works. There is in the request object (typically called $r) a field for my purpose ? (I thought to use ap_pool but I didn't find any information about using it via Perl..) Thanx, Alberto -- Alberto Canzi OpenFor s.r.l. e-mail: [EMAIL PROTECTED]
Re: help about ap_pool in Perl
I need to save some status informations about each request (in my filter each request passes through 3 phases : PerlTransHandler, PerlAccessHandler and PerlHandler. You want $r-pnotes. - Perrin
Errors when trying to use AuthAny.pm
Hi all. I am relatively new to mod_perl so try to bear with me. I am trying to use
the AuthAny.pm module to provide some basic authentication. First off.. Do I put it in
the same directory as Registry.pm? That is where I have it now. In my httpd.conf file
I put the following in:
Location /tools
AuthName Test
AuthType Basic
PerlAuthenHandler AuthAny
require valid-user
/Location
/VirtualHost
I am running on a cobalt raq 3. Here is what I have in AuthAny.pm:
package Apache::AuthAny;
# file: Apache/AuthAny.pm
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
my $user = $r-connection-user;
unless($user and $sent_pw) {
$r-note_basic_auth_failure;
$r-log_reason(Both a username and password must be provided, $r-filename);
return AUTH_REQUIRED;
}
return OK;
}
1;
__END__
The error log message is:
[Wed Jul 11 09:04:59 2001] [error] (2)No such file or directory: access to /tools/
failed for nr2-216-196-142-76.fuse.net, reason: User not known to the underlying
authentication module
Am I missing something here? I am using the standard apache that came with the raq.
Thanks for any help!
Justin
==
Justin Rains
WSI.com Consulting
http://www.wsicnslt.com/
_
Buy gift certificates online @ http://gc.portalplanet.com/
Re: boot_IO error
On Tue, Jul 10, 2001 at 09:34:18PM -0500, Matt Glosson wrote: Hello. I've searched the internet and found many things relating to this, but I thought I would present my own specific problem. I'm trying to install mod_perl with IBM HTTP Server (which is really just apache 1.3.12) on AIX 4.3.3. Everything installs fine, but when I tried to use Net::LDAP, apache segfaults. When I analyze the core file, I'm told that boot_IO is where the problem occurred. Has anyone conquered this problem? The mod_perl readme says that if you are installing on AIX with perl 5.00503 you have to apply a patch to prevent segfaulting when an XS module is called. I applied it and re-compiled. I also tried using perl 5.6.1, which yielded the same results. I've traced it down to the 'use IO::Handle;' clause. I'm using the VisualAge C (vac) compiler to compile everything (gcc hasn't worked very well for most things on this platform.) Well, I repeat a post from me in April here: There have been quite a few problems getting modperl and assorted sub-modules to work since the change that httpd uses the AIX native dlopen under AIX 4.3 and above. In particular this conflicts with perl, as this still uses the dlopen emulation code. Older AIX versions where both httpd and perl use the dlopen layer are not affected. I have put together a patch to Apache, perl and modperl that also turns on runtime linking (-brtl), which makes the AIX dynamic loading behave more like the ELF style dynamic linking. In particular this fixes problems with modules like Apache::Request and HTML::Embperl that need to reference symbols from both httpd and modperl with modperl either linked statically into httpd or as DSO. Perl after this patch also uses the AIX native dlopen, thus if you need binary compatibility to older compiled perl modules do not use this patch. The dlopen emulation code used deferred imports which the native dlopen does not handle. The patch is in three parts and can be found at: http://www.han.de/~jum/aix/ download the following files: apache_1.3.19.rtl.patch modperl.rtl.patch perl-5.6.1.dlopen.patch The apache_1.3.19.rtl.patch does also apply to 1.3.20 cleanly. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
Re: can't start apache-1.3.20 with mod_perl and Mason
On Wed, 11 Jul 2001, Louis-David Mitterrand wrote: Will I have to build a debugging-enabled libperl to get relevant information? Or is this enough to understand the problem? libperld would help, all i can tell is that something in %SIG is being caught, which normally shouldn't happen at startup. are you assigning anything to %SIG ? you could also try this to get the perl filename:line where the segv happens: (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo
Re: Error in PerlRun
On Mon, 9 Jul 2001, Surat Singh Bhati wrote:
Hi,
I am not able to run the mod_perl scriptsd as with
Apache::PerlRun, Apache::Registry is working fine.
PerlRun says :
filename not found or unable to stat
and gives the 404 error.
The file is exists there with proper permission, I am able to run same
file with Apache::Registry
I changed the PerlRun.pm as:
-35 if (-r $r-finfo -s _) {
+35 if (-r $filename -s _) {
hmm, not sure why it isn't working, but this isn't the first problem
reported with $r-finfo. i think i will apply your patch, the finfo
feature clearly isn't as stable as it should be.
RE: detecting ssl
- Original Message -
From: Issac Goldstand [EMAIL PROTECTED]
To: Geoffrey Young [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 10, 2001 3:58 PM
Subject: Re: detecting ssl
-Original Message-
From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 10:44 AM
To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on
port 443 which
will be accessable by https://nasty.servername/ but will, in
reality, not
necessarily be over a secure connection.
what would negotiate the https protocol then? its not like
you can just
set
up to listen on 443, make
a an http request, and Apache will serve it - at least not through a
browser
or telnet.
Of course it will!!!
whoops, I meant an https request - of course you can listen on any port
you
want for plain http.
Then, you are correct. Of course you could simply just pipe the telnet
session through stunnel, or openssl, or whatever - and work something out
like that. But the point is, then it really IS an HTTP request going over
SSL, so mod_ssl will jump in and set $ENV{HTTPS} anyway, so that really
doesn't say anything.
[snip]
Also,
if I'd use a
simple client that just used https as port 443 without
automatically trying
to use a secure layer (which is actually proper...), I could even grab
https:// from the URI request.
ok, I'm not claiming to be an ssl expert, so how would one do that? if
I
do
telnet my.ssl-enabled.server 443
GET / HTTP/1.0
I get 400 - BAD_REQUEST. something has to negotiate the https layer,
no?
Of course. My point is that just because the server's listening on port
443, it doesn't necessarily mean it's using SSL. That's where the danger
is. By checking for $ENV{HTTPS}, you are eliminating that danger by
actually checking whether the individual requests are occuring over a
secure
layer, rather than counting on the server and client to do what you would
expect them to - which is the worst mistake that we, as programmers, can
afford to make... :-)
I've been searching for documentation, but all I can find is the TLS
spec,
which says that TLS is relegated to the scheme of 'https', so pointers
to
something useful would probably be good (for all :)
Umm... If the RFCs aren't helpful, you can try fooling around with (and
reading the man page for) openssl's s_client mode...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
RE: announce: mod_perl-1.25_01
- Original Message - From: Doug MacEachern [EMAIL PROTECTED] To: Christian Gilmore [EMAIL PROTECTED] Cc: 'Modperl Mailing List (E-mail)' [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 12:47 PM Subject: RE: announce: mod_perl-1.25_01 On Tue, 10 Jul 2001, Christian Gilmore wrote: Hrm. Ok, I'll have to release new versions of my modules that have tests for mod_perl 1.26. At what release level do you expect this patch to be committed? well, i don't want to make any promises like i did for 1.26 :)
Re: detecting ssl
I agree with Vivek. With an URL in the format: protocol://hostname:port The browser will use protocol to connect to hostname on port. If you don't specify port, then the browser will pick the default port for protocol, but if the server is not serving the specified protocol on the default port, you won't get anywhere. From: Vivek Khera [EMAIL PROTECTED] Organization: Khera Communications, Inc., Rockville, MD Newsgroups: ml.apache.modperl Date: 11 Jul 2001 15:17:11 -0400 To: [EMAIL PROTECTED] Subject: Re: detecting ssl IG == Issac Goldstand [EMAIL PROTECTED] writes: IG Not necessarily. I could easily set up any virtualhost on port IG 443 which will be accessable by https://nasty.servername/ but IG will, in reality, not necessarily be over a secure connection. I think you've never actually tried this. You will not get the page because the client is expecting SSL and you're not providing it. Try it. Go ahead, try it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: [ANNOUNCE] Hello World Benchmarks, updated
One thing caught my eye; how come mod_perl handler (808.4 hits per second) performed better than HTML static (768.2 hits per second)? And sorry for my newbie-ish question, but what is the difference between mod_perl handler and Apache::Registry mod_perl?
Re: [ANNOUNCE] Hello World Benchmarks, updated
Good work as usual, Joshua. mod_caucho used to look a lot faster, but my testing methodology changed. I used to take the results of the second benchmark run, and publish those, but this time only ran the -test for minor caching after starting resin ( tomcat ). So, I'm guessing that mod_caucho compiles aggresively in the beginning, killing performance for a dry run ( even 60 seconds! ). To improve the numbers for mod_caucho using this methodology might require and longer test cycle than 60 seconds. Ouch! I would think it's worth doing one full run to prime each system. Or do you feel a need to include the initial compilation time? - Perrin
Re: [ANNOUNCE] Hello World Benchmarks, updated
Good work as usual, Joshua. mod_caucho used to look a lot faster, but my testing methodology changed. I used to take the results of the second benchmark run, and publish those, but this time only ran the -test for minor caching after starting resin ( tomcat ). So, I'm guessing that mod_caucho compiles aggresively in the beginning, killing performance for a dry run ( even 60 seconds! ). To improve the numbers for mod_caucho using this methodology might require and longer test cycle than 60 seconds. Ouch! I would think it's worth doing one full run to prime each system. Or do you feel a need to include the initial compilation time? - Perrin
Re: [ANNOUNCE] Hello World Benchmarks, updated
Perrin Harkins wrote: mod_caucho used to look a lot faster, but my testing methodology changed. I used to take the results of the second benchmark run, and publish those, but this time only ran the -test for minor caching after starting resin ( tomcat ). So, I'm guessing that mod_caucho compiles aggresively in the beginning, killing performance for a dry run ( even 60 seconds! ). To improve the numbers for mod_caucho using this methodology might require and longer test cycle than 60 seconds. Ouch! I would think it's worth doing one full run to prime each system. Or do you feel a need to include the initial compilation time? I do feel that compile time matters, but really with 60 seconds and high MaxRequestsPerChild, these systems are getting plenty of compiling caching., these are thousands of requests we are talking about, what if we had lower MaxRequests, or big sites with lots of templates ... if we wanted to do away with compile time entirely, we'd make sure that each system got to precompile all its templates like Apache::RegistryLoader, Apache::ASP-Loader() Embperl's Execute() in the parent httpd. Gerald suggested this before I think it could be good, but for two reasons: compile time is a very real problem for some types of apps like large web sites, and there is an increased burden on optimizing each benchmark, which implies an expertise in the development environment that many users may not have normally. I have been trying for more out of box benchmarks, and not highly optimized benchmarks, using mostly the shipping config for a system. I have thought about having lower MaxClients as an option to the bench to help test compile times, but this doesn't affect the java engines which effectively have their own backend web servers running, like mod_proxy/mod_perl dual httpds. People have suggested before ( you? ) to do two runs, and average the results, and I think that this is a fair approach, and might be better than just doubling the test time because the systems might interact, better yet, do them in one order, and then reverse them, to average out sequential interactions of the tests on a system ( ??? ) --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Using mod_perl handlers for max speed?
In the recent Hello World 2000 benchmark posted by Joshua Chamas, mod_perl
handler was shown to be even faster than static HTML (at least for running
hello world), and twice as fast as using Apache::Registry to run a perl
script.
Does this mean that if there's a heavily used script on my system that
needs to be VERY fast, then it may be worth making it into a mod_perl
handler? What are the caveats of using mod_perl handlers instead of normal
scripts?
For those who didn't see it, here is the code for the Hello World mod_perl
handler program. It is inserted into httpd.conf directly.
Files ~ (hello\.bench)
Perl
# ModPerl Handler
package Apache::bench;
sub handler {
my(\$r) = shift;
\$r-content_type('text/html');
\$r-send_http_header();
\$r-print('Hello ');
\$r-print('World');
200;
}
1;
/Perl
SetHandler perl-script
PerlHandler Apache::bench
/Files
Re: [ANNOUNCE] Hello World Benchmarks, updated
I do feel that compile time matters, but really with 60 seconds and high MaxRequestsPerChild, these systems are getting plenty of compiling caching. The thing is, if mod_caucho takes 5 seconds the first time it hits each template, but is the fastest afterwards, these numbers don't give a very accurate picture of that. Most people expect a hit on the first access. if we wanted to do away with compile time entirely, we'd make sure that each system got to precompile all its templates like Apache::RegistryLoader, Apache::ASP-Loader() Embperl's Execute() in the parent httpd. No need for anything that fancy. I'd say just run the test once as a primer and throw away the results, like you were doing before. It could be for 10 seconds instead of 60. compile time is a very real problem for some types of apps like large web sites, and there is an increased burden on optimizing each benchmark, which implies an expertise in the development environment that many users may not have normally. I have been trying for more out of box benchmarks, and not highly optimized benchmarks, using mostly the shipping config for a system. I feel like allowing the templates to compile isn't tuning, just ignoring startup costs. People have suggested before ( you? ) to do two runs, and average the results, and I think that this is a fair approach, and might be better than just doubling the test time because the systems might interact, better yet, do them in one order, and then reverse them, to average out sequential interactions of the tests on a system ( ??? ) I wouldn't worry about them interacting so much, but I did suggest running multiple times and averaging. I think it helps smooth out random bad runs, which do happen now and then. Any numbers on the new Apache::ASP CGI mode? - Perrin
Re: Using mod_perl handlers for max speed?
Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? Not unless you get astonishing amounts of traffic and your script does almost nothing. These are very simple test cases, so they exaggerate the speed differences. (Intentionally.) However, you should be aware that handlers rock, and many of us consider them more fun than Registry scripts. Registry scripts have their fans as well, of course. What are the caveats of using mod_perl handlers instead of normal scripts? You can read more here: http://perl.apache.org/guide/porting.html#Transitioning_from_Apache_Regis - Perrin
Re: Using mod_perl handlers for max speed?
Philip Mak wrote: In the recent Hello World 2000 benchmark posted by Joshua Chamas, mod_perl handler was shown to be even faster than static HTML (at least for running hello world), and twice as fast as using Apache::Registry to run a perl script. Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? What are the caveats of using mod_perl handlers instead of normal scripts? Its hard to explain, but try not to focus on the Hits/sec, instead look at the sec/Hits. Notice that the difference between Registry CGI Raw and mod_perl handler is only ~ .00025 seconds. Test Name Test File Hits/sec Total Hits Total Time sec/Hits Bytes/Hit -- -- -- -- -- -- Apache::Registry v2.01 CGI Raw hello_raw. 669.9 40196 hits 60.00 sec 0.001493 52 bytes mod_perl handlerhello.benc 808.4 48522 hits 60.02 sec 0.001237 197 bytes You could easily use that much time with a half page of perl code for your application depending on what its doing, especially if you are doing some heavy lifting like writing to a file, or talking to a database. Now if all you want to do is send a Location: header, and have apache write to the access_log, then you might want to start rewriting some of your scripts as mod_perl handlers. Here's another way to look at Hits/sec as being bad to focus on. Let's say you have something that is 1000/sec and something that is 2000/sec, that's only .0005 different. Most of the time that .0005 is negligible compared to the time you will spend in the executing part of the application, which lets say is .01 in execution time, now the overall execution time is .0110 and .0105 which is 91/sec vs. 95/sec respectively. So what looked like something to be twice as fast is now only 4% faster. But if you write some little fast code, then it can make all the difference in the world. The reason I like Hello World, is that it lets me know the fastest I can go in that app, but there's no guarantees I'll get there. :) --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: [ANNOUNCE] Hello World Benchmarks, updated
Perrin Harkins wrote: I do feel that compile time matters, but really with 60 seconds and high MaxRequestsPerChild, these systems are getting plenty of compiling caching. The thing is, if mod_caucho takes 5 seconds the first time it hits each template, but is the fastest afterwards, these numbers don't give a very accurate picture of that. Most people expect a hit on the first access. I get it, but I don't like it... why should an app get to spend ( hypothetically ) 60 seconds compiling a template into highly optimized assembly at runtime, and not have to show this cost in the benchmark. I'd be willing to run a test for longer, or run it multiple times, but to entirely throw out the compilation phase results just seems wrong to me. I'd like to see some middle ground here. No need for anything that fancy. I'd say just run the test once as a primer and throw away the results, like you were doing before. It could be for 10 seconds instead of 60. Another reason not to throw out the results is that it represents a legitimate web request as part of the apps life cycle. There might be some user sitting at the end of that 5 second delay. But then if we talk about throwing out highs lows this starts to sound almost scientific. Like run 10 time slices, throw out the highest lowest times? I wouldn't worry about them interacting so much, but I did suggest running multiple times and averaging. I think it helps smooth out random bad runs, which do happen now and then. Any numbers on the new Apache::ASP CGI mode? Horrid. Won't set up a benchmark yet, but its something like 3 hits/sec on my system compared with mod_cgi CGI.pm which is 11 hits/sec. ASP won't be optimized for mod_cgi type execution any time soon, which would require not loading in all the code per request which it does now for best mod_perl use. --Josh
Re: [ANNOUNCE] Hello World Benchmarks, updated
On Wed, 11 Jul 2001, Philip Mak wrote: And sorry for my newbie-ish question, but what is the difference between mod_perl handler and Apache::Registry mod_perl? http://perl.apache.org/guide/performance.html#Apache_Registry_PerlHandler_vs_ including the benchmarks _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Using mod_perl handlers for max speed?
[EMAIL PROTECTED] (Philip Mak) wrote: Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? What are the caveats of using mod_perl handlers instead of normal scripts? The basic idea is this: with a handler, you're adding new capabilities to the server itself. With a script (CGI or Registry or otherwise), your functionality becomes a resource outside the server, and the server must check that resource, manage it, and cater to its interface needs. How aggressively the server manages reloading, etc. varies from one scheme to another, but that additional stuff is the reason Registry scripts are usually slower than handlers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
APXS make problems with mod_perl 1.26
I've successfully performed the same APXS make with mod_perl 1.25 and 1.25_01, but it breaks with the following error with 1.26: perl Makefile.PL USE_APXS=1 \ WITH_APXS=/usr/local/apache_1.3.20/bin/apxs \ PERL_STACKED_HANDLERS=1 PERL_USELARGEFILES=0 [standard Makefile.PL output is fine...] [root@box593 mod_perl-1.26]# make (cd ./apaci PERL5LIB=/usr/src/mod_perl-1.26/lib make) make[1]: Entering directory `/usr/src/mod_perl-1.26/apaci' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/mod_perl-1.26/apaci' make[1]: Entering directory `/usr/src/mod_perl-1.26/Apache' cc -c -I../ -I/usr/local/apache_1.3.20/include -I/usr/local/apache_1.3.20/include -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.27\ -DXS_VERSION=\1.27\ -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE Apache.c Apache.xs:51: mod_perl.h: No such file or directory Apache.xs:52: mod_perl_xs.h: No such file or directory Apache.xs:292: parse error make[1]: *** [Apache.o] Error 1 make[1]: Leaving directory `/usr/src/mod_perl-1.26/Apache' make: *** [subdirs] Error 2 [root@box593 mod_perl-1.26]# end output perl 5.6.0, apache 1.3.20, kern 2.2.19, gnu make 3.77, married 1.0, children 0.0, home 1.0, bathrooms 1.5
Re: APXS make problems with mod_perl 1.26
On Wed, 11 Jul 2001, Neil Mansilla wrote: I've successfully performed the same APXS make with mod_perl 1.25 and 1.25_01, but it breaks with the following error with 1.26: perl Makefile.PL USE_APXS=1 \ WITH_APXS=/usr/local/apache_1.3.20/bin/apxs \ PERL_STACKED_HANDLERS=1 PERL_USELARGEFILES=0 [standard Makefile.PL output is fine...] that works just fine here, however.. make[1]: Entering directory `/usr/src/mod_perl-1.26/Apache' cc -c -I../ -I/usr/local/apache_1.3.20/include -I/usr/local/apache_1.3.20/include -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.27\ -DXS_VERSION=\1.27\ -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE Apache.c Apache.xs:51: mod_perl.h: No such file or directory Apache.xs:52: mod_perl_xs.h: No such file or directory Apache.xs:292: parse error .. i had exactly the same error when i first tried, in a mod_perl-1.26 directory i had earlier built with other options, including DYNAMIC=1 the new build tried to compile the old Apache/Apache.c did you happen to try another build in that tree prior?
[ANNOUNCE] Apache::ASP v2.19
Hey, The latest release of Apache::ASP, v2.19, is out. You can get it in your local CPAN or here: http://www.perl.com/CPAN-local/modules/by-module/Apache/ The big development in the module is a standalone CGI mode that works without mod_perl, at least on Linux where I tested it. The rest are tweaks and documentation updates. The CHANGES are below. Apache::ASP provides an Active Server Pages port to the Apache Web Server with Perl scripting only, and enables developing of dynamic web applications with session management and embedded perl code. There are also many powerful extensions, including XML taglibs, XSLT rendering, and new events not originally part of the ASP API! Regards, Josh =item $VERSION = 2.19; $DATE=7/10/2001; +update docs in various parts +added ./make_httpd/build_httpds.sh scripts for quick builds of apache + mod_perl + mod_ssl ++plain CGI mode available for ASP execution. cgi/asp script can now be used to execute ASP scripts in CGI mode. See CGI perldoc section for more info. The examples in ./site/eg have been set up to run in cgi mode if desired. Configuration in CGI section only tested for Apache on Linux. -Fixed some faulty or out of date docs in XML/XSLT section. +added t/server_mail.t test for $Server-Mail(), requires Net::SMTP to be configured properly to succeed. +Net::SMTP debugging not enabled by Debug 1,2,3 configs, not only when system debugging is set with Debug -1,-2,-3 However, a Debug param passed to $Server-Mail() will sucessfully override the Debug -1,-2,-3 setting even when its Debug = 0 -Check for undef values during stats for inline includes so we don't trigger unintialized warnings +Documented ';' may separate many directories in the IncludesDir setting for creating a more flexible includes search path.
[ANNOUNCE] Hello World Benchmarks, updated
Hey, The latest Hello World benchmarks at available at: http://www.chamas.com/bench/hello.tar.gz To reproduce the BELOW results on your platform, for whatever tests are available, run: ./bench.pl -test ./bench.pl -version -time=60 --Josh DISCLAIMER: these benchmarks test only what they test for, and I try to make no assertions about the fitness of any system for your needs. They are open source, feel free to critique the tests as you like, and provide constructive feedback. CHANGES: New HTML::Template 2000 test. My system is newly built with apache 1.3.20, mod_perl 1.25. NOTES: mod_perl The mod_perl environments are starting to look faster than PHP. Maybe something in the default mod_perl 1.25 gave a performance boost? mod_caucho used to look a lot faster, but my testing methodology changed. I used to take the results of the second benchmark run, and publish those, but this time only ran the -test for minor caching after starting resin ( tomcat ). So, I'm guessing that mod_caucho compiles aggresively in the beginning, killing performance for a dry run ( even 60 seconds! ). To improve the numbers for mod_caucho using this methodology might require and longer test cycle than 60 seconds. HTML::Embperl 2.0 series is much faster ( than PHP ASP too), but 1.3.0 is stable, installable from CPAN, so I run that. HTML::Mason 1.0 version used to be much faster on 2000 benchmark mod_jserv Why is the hello bench slower than the 2000 bench? I don't know. It may be a funny caching strategy. It may be the JVMs were cleaning up from the 2000 test during the hello test. Speculation only, as I don't know much about java. HTML static for the first time, looks slower on my system than mod_perl. It may be that the default 1.3.20 apache install/config does more work on the headers. Also this is a dual proc system which has slowed down the HTML static test before, relative to single CPU systems. Test Name Test File Hits/sec Total Hits Total Time sec/Hits Bytes/Hit -- -- -- -- -- -- Apache::ASP v2.19 2000 h2000.asp 226.2 13578 hits 60.02 sec 0.004421 28998 byte Apache::Registry v2.01 2000 mod_per h2000.reg 339.5 20376 hits 60.02 sec 0.002945 28179 byte HTML::Embperl v1.3.0 2000 h2000.epl 111.3 6677 hits 60.00 sec 0.008987 28841 byte HTML::Mason v1.03 2000 h2000.mas83.5 5014 hits 60.02 sec 0.011969 28799 byte HTML::Template v2.3 2000h2000.htmp 98.2 5892 hits 60.00 sec 0.010183 29152 byte mod_caucho JSP 2000 h2000.jsp76.6 4595 hits 60.01 sec 0.013060 28965 byte mod_jserv JSP 2000 h2000.jsp 150.0 9002 hits 60.02 sec 0.006667 29408 byte mod_php PHP 2000h2000.php 228.4 13705 hits 60.01 sec 0.004379 28866 byte Template v2.04 Toolkit 2000 h2000.tt 52.9 3176 hits 60.02 sec 0.018900 28889 byte Apache::ASP v2.19 hello.asp 378.3 22706 hits 60.02 sec 0.002643 242 bytes Apache::Dispatch v0.09 handler hello/worl 587.6 35259 hits 60.01 sec 0.001702 197 bytes Apache::ePerl hello.eper 345.5 20742 hits 60.03 sec 0.002894 218 bytes Apache::Registry v2.01 CGI Raw hello_raw. 669.9 40196 hits 60.00 sec 0.001493 52 bytes Apache::Registry v2.01 CGI.pm hello.cgi 448.6 26924 hits 60.02 sec 0.002229 217 bytes Apache::SSI v2.16 hello.shtm 533.8 32029 hits 60.00 sec 0.001873 200 bytes HTML static hello.html 768.2 46120 hits 60.04 sec 0.001302 312 bytes HTML::Embperl v1.3.0hello.epl 459.8 27595 hits 60.01 sec 0.002175 221 bytes HTML::Mason v1.03 hello.mas 373.3 22406 hits 60.02 sec 0.002679 198 bytes HTML::Template v2.3 hello.htmp 535.9 32165 hits 60.02 sec 0.001866 199 bytes mod_caucho JSP hello.jsp88.1 5321 hits 60.37 sec 0.011345 231 bytes mod_cgi CGI Raw hello_raw. 153.5 9210 hits 60.00 sec 0.006515 197 bytes mod_cgi CGI.pm hello.cgi11.0 662 hits 60.02 sec 0.090660 217 bytes mod_include SSI hello.shtm 223.2 13396 hits 60.03 sec 0.004481 199 bytes mod_jserv JSP hello.jsp53.5 3223 hits 60.29 sec 0.018706 358 bytes mod_perl handlerhello.benc 808.4 48522 hits 60.02 sec 0.001237 197 bytes mod_php PHP hello.php 665.9 39954 hits 60.00 sec 0.001502 226 bytes mod_speedycgi hello.cgi
cvs commit: modperl Changes
dougm 01/07/11 08:12:11
Modified:lib/Apache PerlRun.pm
.Changes
Log:
remove $r-finfo usage from Apache::PerlRun, clearly finfo isn't as
stable as it should be
Revision ChangesPath
1.37 +3 -1 modperl/lib/Apache/PerlRun.pm
Index: PerlRun.pm
===
RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- PerlRun.pm2001/01/29 22:13:40 1.36
+++ PerlRun.pm2001/07/11 15:11:57 1.37
@@ -32,7 +32,9 @@
my($pr) = @_;
my $r = $pr-{r};
my $filename = $r-filename;
-if (-r $r-finfo -s _) {
+#XXX reported problems with $r-finfo
+#if (-r $r-finfo -s _) {
+if (-r $filename -s _) {
if (!($r-allow_options OPT_EXECCGI)) {
$r-log_reason(Options ExecCGI is off in this directory,
$filename);
1.613 +4 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.612
retrieving revision 1.613
diff -u -r1.612 -r1.613
--- Changes 2001/07/11 03:02:28 1.612
+++ Changes 2001/07/11 15:12:06 1.613
@@ -10,6 +10,10 @@
=item 1.25_02-dev
+remove $r-finfo usage from Apache::PerlRun, clearly finfo isn't as
+stable as it should be
+[Surat Singh Bhati [EMAIL PROTECTED]]
+
Apache-server will now point the current VirtualHost when inside a
Perl section, thanks to Robin Berjon for the spot
cvs commit: modperl/lib mod_perl.pm
dougm 01/07/11 19:12:04
Modified:.Changes
lib mod_perl.pm
Log:
1.26
Revision ChangesPath
1.615 +1 -1 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.614
retrieving revision 1.615
diff -u -r1.614 -r1.615
--- Changes 2001/07/12 01:32:55 1.614
+++ Changes 2001/07/12 02:12:00 1.615
@@ -8,7 +8,7 @@
=over 3
-=item 1.25_02-dev
+=item 1.26 - July 11, 2001
fix 'make test' problem seen with Perl 5.005_03
1.52 +1 -1 modperl/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl/lib/mod_perl.pm,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- mod_perl.pm 2001/07/06 21:27:41 1.51
+++ mod_perl.pm 2001/07/12 02:12:03 1.52
@@ -4,7 +4,7 @@
use DynaLoader ();
BEGIN {
-$mod_perl::VERSION = 1.2502;
+$mod_perl::VERSION = 1.26;
}
sub boot {
cvs commit: modperl/lib mod_perl.pm
dougm 01/07/11 19:27:29
Modified:.Changes
lib mod_perl.pm
Log:
bump version
Revision ChangesPath
1.616 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.615
retrieving revision 1.616
diff -u -r1.615 -r1.616
--- Changes 2001/07/12 02:12:00 1.615
+++ Changes 2001/07/12 02:27:25 1.616
@@ -8,6 +8,8 @@
=over 3
+=item 1.26_01-dev
+
=item 1.26 - July 11, 2001
fix 'make test' problem seen with Perl 5.005_03
1.53 +1 -1 modperl/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl/lib/mod_perl.pm,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- mod_perl.pm 2001/07/12 02:12:03 1.52
+++ mod_perl.pm 2001/07/12 02:27:28 1.53
@@ -4,7 +4,7 @@
use DynaLoader ();
BEGIN {
-$mod_perl::VERSION = 1.26;
+$mod_perl::VERSION = 1.2601;
}
sub boot {
cvs commit: modperl/t/net/perl test
dougm 01/07/11 18:32:59
Modified:.Changes
t/net/perl test
Log:
fix 'make test' problem seen with Perl 5.005_03
Revision ChangesPath
1.614 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.613
retrieving revision 1.614
diff -u -r1.613 -r1.614
--- Changes 2001/07/11 15:12:06 1.613
+++ Changes 2001/07/12 01:32:55 1.614
@@ -10,6 +10,8 @@
=item 1.25_02-dev
+fix 'make test' problem seen with Perl 5.005_03
+
remove $r-finfo usage from Apache::PerlRun, clearly finfo isn't as
stable as it should be
[Surat Singh Bhati [EMAIL PROTECTED]]
1.18 +1 -1 modperl/t/net/perl/test
Index: test
===
RCS file: /home/cvs/modperl/t/net/perl/test,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- test 2000/10/10 16:34:02 1.17
+++ test 2001/07/12 01:32:58 1.18
@@ -60,7 +60,7 @@
#$r-warn(sequence number: . $r-seqno);
if($Apache::TestSIG) {
-use Apache::SIG ();
+require Apache::SIG;
Apache::SIG-set;
}
cvs commit: modperl Makefile.PL
dougm 01/07/11 18:34:46
Modified:.Makefile.PL
Log:
fixes for building with 5.004
Revision ChangesPath
1.193 +4 -2 modperl/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.192
retrieving revision 1.193
diff -u -r1.192 -r1.193
--- Makefile.PL 2001/07/10 15:45:21 1.192
+++ Makefile.PL 2001/07/12 01:34:44 1.193
@@ -341,7 +341,7 @@
if($k eq 'PREFIX')
{
- use File::Spec;
+ require File::Spec;
$MOD_PERL_PREFIX =
File::Spec-catfile($v,'lib','site_perl',$Config{'version'},$Config{'archname'});
}
@@ -2043,7 +2043,9 @@
PERL_STATIC_EXTS PERL_SSI PERL_SECTIONS USE_APXS
WITH_APXS);
{
no strict 'refs';
-$my_config{$_} = ${$_} for @other_hooks;
+for (@other_hooks) {
+$my_config{$_} = ${$_};
+}
}
if ($win32_auto) {
for (qw(APACHE_INC APACHE_LIB MODPERL_INC MODPERL_LIB)) {
