handler not being called
Hi..
I have added a handler entry in httpd.conf
location /myhandler
SetHandler perl-script
PerlHandler Demo
/Location
and I have printed a string inside the handler thats it.
When I do GET on the URI I get the following error.
HTML
HEADTITLEAn Error Occurred/TITLE/HEAD
BODY
H1An Error Occurred/h1
405 Method Not Allowed
/BODY
/HTML
Why isnt the handler being called. The module: Demo.pm is placed in more
than one @INC paths of perl.
Waiting for help
Riz
- Original Message -
From: Francesc Guasch Ortiz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 20, 2002 1:07 PM
Subject: Re: apache dies silently at start with perl-5.6.1 rpm
Kurt Hansen escribió:
Did you see this message from the Mason list? If so, did this solution
not work
for you?
I installed an old Data::Dumper: Data-Dumper-2.101
Right now I have a compiled perl-5.6.1 and these apache-1.3.22-2 rpm.
Now I can start apache with the mason handler, but as soon
as I add some DBI module in the handler.pl, it doesn't work:
{ package HTML::Mason::Commands;
use DBI;
}
--
frankie
Re: Accessing Apache master process pid
Jon Jensen wrote:
On Wed, 20 Mar 2002, Stas Bekman wrote:
Jon Jensen wrote:
Within mod_perl, I would like to know the pid of the master Apache daemon,
perldoc -f getppid
Thanks, Stas. I should've found that. I'm still interested in getting the
PidFile setting at runtime, but can live without it if I have to.
well, here's one other way:
Perl
$Apache::Server::SaveConfig = 1;
$PidFile = 'logs/httpd.pid';
/Perl
PerlInitHandler 'sub { warn The parent pid file is: , \
shift-server_root_relative($Apache::ReadConfig::PidFile)}'
yeilds:
The parent pid file is: /usr/local/apache/logs/httpd.pid at (eval 312)
line 1.
if you really need access to ap_pid_fname() that looks easy enough,
but justification for needing it would help doug make the
architectural decision whether to include it or not in core.
HTH
--Geoff
RE: mod_perl does not see multipart POSTs
I tried the code. Still nothing. I did turn On PerlWarn in httpd.conf.
Upon restart I saw the following:
errorlog
[Wed Mar 20 07:55:19 2002] [info] master_main: Restart event signaled. Doing
a graceful restart.
defined(@array) is deprecated at C:/Perl/site/lib/Apache/DBI.pm line 135.
(Maybe you should just omit the defined()?)
[Wed Mar 20 07:55:21 2002] [info] Parent: Created child process 2936
[Wed Mar 20 07:55:21 2002] [info] Parent: Duplicating socket 244 and sending
it to child process 2936
[Wed Mar 20 07:55:22 2002] [info] BytesRead = 372 WSAProtocolInfo = 2006620
[Wed Mar 20 07:55:26 2002] nul: Use of uninitialized value in subroutine
entry at C:/Perl/site/lib/Apache.pm line 61.
/errorlog
I am not sure where the Apache::DBI error crept in, but I believe it is
unrelated. As for line 61 of Apache, I do not know if this is a warning I
can ignore or not.
Also, as for not using parse() -- it was my understanding it was not
necessary to call explicitly, however you could use the status to provide
some error catching. . .
Is there a bare-bones httpd.conf file I can use to run mod_perl? I am
presuming it is my configuration of Apache that might be causing problems.
I have the latest mod_perl, apache modules, and apache that I am aware of.
completely befuddled now. :|
Thanks,
Ward
: -Original Message-
: From: Randy Kobes [mailto:[EMAIL PROTECTED]]
: Sent: Tuesday, March 19, 2002 9:24 PM
: To: Vuillemot, Ward W
: Cc: 'Issac Goldstand'; [EMAIL PROTECTED]
: Subject: Re: mod_perl does not see multipart POSTs
:
:
:
: - Original Message -
: From: Vuillemot, Ward W [EMAIL PROTECTED]
: To: 'Issac Goldstand' [EMAIL PROTECTED];
: [EMAIL PROTECTED]
: Sent: Tuesday, March 19, 2002 2:30 PM
: Subject: RE: mod_perl does not see multipart POSTs
:
:
: I simplified everything to the bare bones. Nothing is
: getting passed. I
: am
: at a complete loss. If anyone has a few minutes, just
: try running this.
: You should be able to point it toward a text/plain file
: and have it
: displayed below the file upload form.
:
: I'm not quite sure what the full requirements are, but
: the following
: works for me in displaying the contents of the uploaded
: file - this
: is on Win32 with the latest mod_perl/libapreq packages.
:
: In httpd.conf:
: **
: PerlModule Apache::testUpload
: Location /testUpload
:SetHandler perl-script
:PerlHandler Apache::testUpload
:PerlSendHeader Off
: /Location
: **
: and Apache/testUpload.pm is
:
: package Apache::testUpload;
: use strict;
: ##
: ### START LOADING MODULES ###
: ##
: use Apache::Request ();
: use CGI;
: use Apache::Constants qw(:common);
: ##
: ### HANDLER###
: ##
: sub handler{
:my $q = Apache::Request-new(shift, DISABLE_UPLOADS = 0,
:POST_MAX = 2048);
:return main($q);
: }
:
: ##
: ### START OF MAIN LOGIC ###
: ##
: sub main{
:my $q = shift;
:my $status = $q-parse();
:return $status unless $status == OK;
:my %results = ();
:my $cgi = CGI-new();
:#
:## START FORM ##
:#
:$results{content} .= $cgi-start_multipart_form;
:$results{content} .= $cgi-filefield(-name='uploaded_file',
: -default='starting value',
: -size=50,
: -maxlength=80);
:$results{content} .= $cgi-submit();
:$results{content} .= $cgi-endform;
:#
:## START UPLOAD FILE ##
:#
:my $upload = $q-upload || undef;
:if ($upload) {
: my $fh = $upload-fh;
: my $filename = $upload-filename;
: my $size = $upload-size;
: $results{content} .= Upload Filebr /;
: $results{content} .= Filename: $filenamebr /;
: $results{content} .= Size: $sizebr /;
: $results{content} .= $_br / while $fh;
:}
:#
:## START OUTPUT##
:#
:# send results to browser
:$q-send_http_header('text/html');
:print $cgi-start_html('File Upload Test');
:print $cgi-h1('Content') . $results{content};
:print $cgi-end_html();
:return OK;
: }
: 1;
: **
:
: Apart from abbreviating the output,
Re: handler not being called
Rizwan Majeed wrote: I have added a handler entry in httpd.conf location /myhandler SetHandler perl-script PerlHandler Demo /Location and I have printed a string inside the handler thats it. Hi Riz, do you load your Module Demo.pm somewhere? E.g. in httpd.conf: PerlModule Demo or in startup.pl use Demo(); And maybe you have to add butter to the fish ;-) - be more verbose in your Location definition. See: http://perl.apache.org/guide/config.html#_Location_Configuration Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * *
RE: mod_perl does not see multipart POSTs
On Wed, 20 Mar 2002, Vuillemot, Ward W wrote: I tried the code. Still nothing. I did turn On PerlWarn in httpd.conf. Upon restart I saw the following: errorlog [Wed Mar 20 07:55:19 2002] [info] master_main: Restart event signaled. Doing a graceful restart. defined(array) is deprecated at C:/Perl/site/lib/Apache/DBI.pm line 135. (Maybe you should just omit the defined()?) [Wed Mar 20 07:55:21 2002] [info] Parent: Created child process 2936 [Wed Mar 20 07:55:21 2002] [info] Parent: Duplicating socket 244 and sending it to child process 2936 [Wed Mar 20 07:55:22 2002] [info] BytesRead = 372 WSAProtocolInfo = 2006620 [Wed Mar 20 07:55:26 2002] nul: Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Apache.pm line 61. /errorlog I am not sure where the Apache::DBI error crept in, but I believe it is unrelated. As for line 61 of Apache, I do not know if this is a warning I can ignore or not. Also, as for not using parse() -- it was my understanding it was not necessary to call explicitly, however you could use the status to provide some error catching. . . Is there a bare-bones httpd.conf file I can use to run mod_perl? I am presuming it is my configuration of Apache that might be causing problems. I have the latest mod_perl, apache modules, and apache that I am aware of. completely befuddled now. :| Thanks, Ward That is strange ... Does a simple mod_perl handler that, eg, just says hello work? What about a simple form that uses Apache::Request to process? You might also verify that you are running the latest version of mod_perl and, especially, libapreq. Are you running on Win32? We have the latest libapreq ppm package for this under http://theoryx5.uwinnipeg.ca/ppmpackages/ - maybe try this if you weren't using it before. The configuration I used for the Apache/testUpload.pm file I sent was just, in the appropriate places, LoadModule perl_module modules/mod_perl.so and, after ClearModuleList (you may not have this), AddModule mod_perl.c as well as the specific ones for testUpload: PerlModule Apache::testUpload Location /testUpload SetHandler perl-script PerlHandler Apache::testUpload PerlSendHeader Off /Location best regards, randy kobes
RE: mod_perl does not see multipart POSTs -- SOLVED
Using the POST2GET snippet was interferring. I thought I had turned it off
when trying Lergon's suggestion. I must not have.
As for the actual code. . .I copied it exactly as Lergon's and it works. I
know what was different, but I swear that what I had was taken verbatim from
mod_perl documentation.
Just for academic purposes.
I had something like
sub handler{
use Apache::Constants qw(:common);
my $r = Apache-request(shift);
main($r);
return OK;
}
sub main{
my $r = shift;
my $q = Apache::Request-new(shift, DISABLE_UPLOADS = 0, POST_MAX
= 204800);
blah blah blah
}
Per Lergon's code I just simplified it to
sub handler{
use Apache::Constants qw(:common);
my $q = Apache::Request-new(shift, DISABLE_UPLOADS = 0, POST_MAX
= 204800);
main($q);
return OK;
}
sub main{
my $q = shift;
blah blah blah
}
To boot, I was using the POST2GET module found at
http://perl.apache.org/guide/snippets.html#Reusing_Data_from_POST_request
Once I got rid of POST2GET and simplified the script ala Lergon's code
things started to work. Sigh.
However, I followed code snippets from
http://perl.apache.org/guide/porting.html#Converting_into_Perl_Content_Han
I guess I either did not read things carefully, or I am missing something.
:( I would imagine I had about 3 solutions going at once -- that is to say
that if any one of them were implemented alone things might have worked. In
conjunction with each other they fumbled each other up.
Oh well.
I do appreciate everyone's time. Hopefully the above information might
prove useful to other people in similar situation.
Cheers,
Ward
: -Original Message-
: From: Ernest Lergon [mailto:[EMAIL PROTECTED]]
: Sent: Tuesday, March 19, 2002 1:30 PM
: To: [EMAIL PROTECTED]
: Subject: Re: mod_perl does not see multipart POSTs
:
:
: Vuillemot, Ward W wrote:
:
: Here is the Apache config
: PerlModule testUpload
: Location /testUpload
: SetHandler perl-script
: PerlHandler testUpload
: PerlSendHeader Off
: # limit POSTS so that they get processed properly
: Limit POST
: PerlInitHandler POST2GET
: /Limit
: /Location
:
:
: Hi Ward,
:
: assumed, you have seen the example from
:
: http://perl.apache.org/guide/snippets.html#Reusing_Data_fr
: om_POST_request
:
: and you have written your own POST2GET.pm, more questions
: are arising:
:
: Is POST2GET.pm loaded anywhere - in a startup.pl or via
: httpd.conf?
:
: Some more hints:
:
: Add 'use warnings;' to your code and look at your error_log.
: CGI.pm should be loaded AND compiled very early.
: Be careful with global vars under mod_perl.
: Look in CPAN to avoid reinventing the wheel:
: http://search.cpan.org/search?mode=modulequery=upload
:
: Ernest
:
:
:
: --
:
: **
: ***
: * VIRTUALITAS Inc. *
:*
: **
:*
: * European Consultant Office *
http://www.virtualitas.net *
* Internationales Handelszentrum * contact:Ernest Lergon *
* Friedrichstraße 95 *mailto:[EMAIL PROTECTED] *
* 10117 Berlin / Germany * ums:+49180528132130266 *
*
Re: mod_perl does not see multipart POSTs -- SOLVED
Vuillemot, Ward W wrote: Using the POST2GET snippet was interferring. I thought I had turned it off when trying Lergon's suggestion. I must not have. As for the actual code. . .I copied it exactly as Lergon's and it works. I know what was different... [snip] Hi Ward, hi Randy! Thank you for the flowers, Ward, but it I don't want to adorn myself with borrowed plumes ;-)) So the hint was mine and the code was Randy's! Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * *
RE: mod_perl does not see multipart POSTs -- SOLVED
Randy, My apologies! Thank you for the code. Ernest, Thanks for the clues! You take your namesake seriously, too. Wonderful! ;) Cheers, Ward
Subroutines taking time to return..
I've been profiling my MySQL driven Mod_Perl website by adding debug
messages throughout the code which relays what time has elapsed since the
script was invoked (using Time::HiRes)
Now the script is pretty whizzy, serving up complete pages in circa 0.010
seconds.
I got to wondering how those 0.010 were being made up. Interestingly, all
of the database access is complete within 0.002 so I thought where do the
other 0.008 come from ?
I found the following happened (pseudo code)
# Checkpoint A - Elapsed : 0.000
buildpage;
# Checkpoint D - Elapsed 0.010 seconds
sub buildpage
{
# Checkpoint B - Elapsed: 0.001
# Do some DB accessing etc. make a nice webpage
# Checkpoint C - Elapsed 0.002
}
--
I expected all the complicated DB access stuff to make up the time, but
instead it seems to be consuming 0.005 in returning from the subroutine to
the main script.
What's that all about ?
Points:
1. A global variable exists throughout the script to build the webpage
2. Global file handles are used to access the DB (to retain across
subsequent requests)
3. No LOCAL or MY variables are defined in the subroutine.
4. As the webpage is being built into a global variable, the buildpage
subroutine doesn't RETURN a value to the calling script.
It SEEMS the subroutine is taking an inordinate amount of time returning to
the main procedure.. why would this be ?
( I'm running Free/BSD, Apache/1.3.22, Mod_perl 1.26 )
Re: mod_perl does not see multipart POSTs -- SOLVED
Vuillemot, Ward W wrote: Using the POST2GET snippet was interferring. I thought I had turned it off when trying Lergon's suggestion. I must not have. As for the actual code. . .I copied it exactly as Lergon's and it works. I know what was different, but I swear that what I had was taken verbatim from mod_perl documentation. Just for academic purposes. Ward, Ernest, can you please send the me the required changes if any so I can update the guide. I wasn't following this discussion, so if you can send a patch that would be very helpful. Thanks. _ 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: Subroutines taking time to return..
Have you tried using Apache::DProf? Using this is a lot easier than
trying to add tons of debug messages. If you haven't used it or the
regular DProf, it does what your doing automatically. It generates a
file of data that you run 'dprofpp' on and you can get a list of the top
10 or so most time consuming functions. Using Apache::DProf usually
reveals time consuming methods in my code that I would never have
expected to take so long.
In your case, however thourough you were in placing debug statements,
its possible (and likely) that you've missed the key subroutine.
G
On Wed, 2002-03-20 at 09:59, David Brown wrote:
I've been profiling my MySQL driven Mod_Perl website by adding debug
messages throughout the code which relays what time has elapsed since the
script was invoked (using Time::HiRes)
Now the script is pretty whizzy, serving up complete pages in circa 0.010
seconds.
I got to wondering how those 0.010 were being made up. Interestingly, all
of the database access is complete within 0.002 so I thought where do the
other 0.008 come from ?
I found the following happened (pseudo code)
# Checkpoint A - Elapsed : 0.000
buildpage;
# Checkpoint D - Elapsed 0.010 seconds
sub buildpage
{
# Checkpoint B - Elapsed: 0.001
# Do some DB accessing etc. make a nice webpage
# Checkpoint C - Elapsed 0.002
}
--
I expected all the complicated DB access stuff to make up the time, but
instead it seems to be consuming 0.005 in returning from the subroutine to
the main script.
What's that all about ?
Points:
1. A global variable exists throughout the script to build the webpage
2. Global file handles are used to access the DB (to retain across
subsequent requests)
3. No LOCAL or MY variables are defined in the subroutine.
4. As the webpage is being built into a global variable, the buildpage
subroutine doesn't RETURN a value to the calling script.
It SEEMS the subroutine is taking an inordinate amount of time returning to
the main procedure.. why would this be ?
( I'm running Free/BSD, Apache/1.3.22, Mod_perl 1.26 )
Re: Apache::DBI startup?
On Wed, 20 Mar 2002, Stas Bekman wrote: Doug Silver wrote: I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Yes see http://perl.apache.org/guide/databases.html#Debugging_Apache_DBI Actually, that's what I had it on: [Wed Mar 20 10:45:16 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0 mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations 30460 Apache::DBI PerlChildInitHandler 30461 Apache::DBI PerlChildInitHandler 30462 Apache::DBI PerlChildInitHandler 30463 Apache::DBI PerlChildInitHandler 30464 Apache::DBI PerlChildInitHandler [Wed Mar 20 10:45:16 2002] [notice] Accept mutex: flock (Default: flock) From my startup.pl: # choose debug output: 0 = off, 1 = quiet, 2 = chatty $Apache::DBI::DEBUG = 2; I guess I just wanted some confirmation on how the DBI was able to establish the connection without a database or username specified. Guess it's working, which is the main issue. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
RE: handler not being called
Can you send the code for Demo.pm?
I have added a handler entry in httpd.conf
location /myhandler
SetHandler perl-script
PerlHandler Demo
/Location
and I have printed a string inside the handler thats it.
When I do GET on the URI I get the following error.
HTML
HEADTITLEAn Error Occurred/TITLE/HEAD
BODY
H1An Error Occurred/h1
405 Method Not Allowed
/BODY
/HTML
Why isnt the handler being called. The module: Demo.pm is placed in more
than one @INC paths of perl.
Waiting for help
Riz
- Original Message -
From: Francesc Guasch Ortiz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 20, 2002 1:07 PM
Subject: Re: apache dies silently at start with perl-5.6.1 rpm
Kurt Hansen escribió:
Did you see this message from the Mason list? If so, did this solution
not work
for you?
I installed an old Data::Dumper: Data-Dumper-2.101
Right now I have a compiled perl-5.6.1 and these apache-1.3.22-2 rpm.
Now I can start apache with the mason handler, but as soon
as I add some DBI module in the handler.pl, it doesn't work:
{ package HTML::Mason::Commands;
use DBI;
}
--
frankie
Re: Subroutines taking time to return..
Hi there, On Wed, 20 Mar 2002, David Brown wrote: I've been profiling my MySQL driven Mod_Perl website [snip] (using Time::HiRes) [snip] I expected all the complicated DB access stuff to make up the time MySQL is pretty quick. :) instead it seems to be consuming 0.005 in returning from the subroutine to the main script. What's that all about ? [snip] It SEEMS the subroutine is taking an inordinate amount of time returning to the main procedure.. why would this be ? What else is the machine doing? Is it reapeatable (i.e. not just OS timeslices or something)? Post the code? 73, Ged.
RE: CGI.pm and POST requests
Hi there, On Wed, 20 Mar 2002, Vuillemot, Ward W wrote: On Tue, 19 Mar 2002 14:06:15 -0800 Vuillemot, Ward W wrote: why would it work for cgi and not mod_perl? From: Ged Haywood [Replying privately because of large attachment] Does the attached version of CGI.pm help? (I have added a few 'print' statements, they are flagged by --GWH-- for you to find them easily.) Run it and then look in the error_log... I have the latest version of CGI. But I am not using it to read in sent data anymore. Since my scripts that use CGI versus Apache::Request are identical except one is run in cgi space versus mod_perl space, one would expect everything to be hunky dory. My point was not that you don't have the latest bersion of CGI.pm. I sent you CGI.pm with some debugging information which will allow you easily to see why things don't do what you expect. It would seem my httpd.conf file is off. No, I don't think that's the problem. Like I said, if you run your scripts with the CGI.pm that I sent you may see something interesting. (I don't want to do the whole thing for you...:) 73, Ged.
[ANNOUNCE] Uttu 0.01 (dev) - web application driver
I finally got enough stuff done and put together that I feel ready to let someone else hammer at the code and tell me where my stupid mistakes are :) Most likely, the documentation will be poor - as usual, it lags a bit behind the code. $CPAN/authors/id/J/JS/JSMITH/Uttu-0.01.tar.gz $CPAN/authors/id/J/JS/JSMITH/Uttu-Framework-Uttu-0.01.tar.gz CPAN may need a little time to propogate files. The first is the base Uttu module. Installing it allows installation of the second to follow the familiar Perl pattern for modules (perl Makefile.PL; make; make install). The second tarball is an example of a framework to be used atop Uttu. READMEs are included. Some debugging code is still lying around, so don't be surprised by scrolling text :) Feel free to email me questions on or off the list. Uttu allows for fairly easy configuration and use of a content handler. Right now, only HTML::Mason is supported. It has been tested with virtual hosts, though not with multiple configured locations within a single host (though it is designed to work even with such a configuration). It also provides uri-to-filename translation and limited internationalization support. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Fwd: performance: using mlock(2) on httpd parent process
I've raised the issue of mlock at the httpd-dev list, Scott Hess
followed up with extensive explanations and most important -- a C code
to verify that memory doesn't go unshared when swapped out. The cool
thing about it being in C is that it's easy to create big chunks of
shared memory. So now you can easily verify the effects discussed at
this list recently.
The conclusing is the same as we always had: don't let your machine
swap, use the memory usage restricting tools for maintaining the desired
memory usage cap.
Original Message
Subject: Re: performance: using mlock(2) on httpd parent process
Date: Wed, 20 Mar 2002 11:08:51 -0800 (PST)
From: Scott Hess [EMAIL PROTECTED]
To: Stas Bekman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
On Thu, 21 Mar 2002, Stas Bekman wrote:
On Wed, 20 Mar 2002, Stas Bekman wrote:
mod_perl child processes save a lot of memory when they can share
memory with the parent process and quite often we get reports from
people that they lose that shared memory when the system decides to
page out the parent's memory pages because they are LRU (least
recently used, the algorithm used by many memory managers).
I'm fairly certain that this is not an issue. If a page was shared
COW before being paged out, I expect it will be shared COW when paged
back in, at least for any modern OS.
But if the system needs to page things out, most of the parent process's
pages will be scheduled to go first, no? So we are talking about a
constant page-in/page-out from/to the parent process as a performance
degradation rather than memory unsharing. Am I correct?
The system is going to page out an approximation of the
least-recently-used pages. If the children are using those pages, then
they won't be paged out, regardless of what the parent is doing. [If the
children _aren't_ using those pages, then who cares?]
[To verify that I wasn't talking through my hat, here, I just verified
this using RedHat 7.2 running kernel 2.4.9-21. If you're
interested in my
methodology, drop me an email.]
I suppose that this could vary from one kernel version to another.
Perhaps, but I doubt it. I can't really do real tests on older kernels
because I don't have them on any machines I control, but I'd be somewhat
surprised if any OS which runs on modern hardware worked this way. It
would require the OS to map a given page to multiple places in the
swapfile, which would be significant extra work, and I can't think of any
gains from doing so.
I'm just repeating the reports posted to the mod_perl list. I've never
seen such a problem myself, since I try hard to have close to zero swap
usage.
:-). In my experience, you can get some really weird stuff happening when
you start swapping mod_perl. It seems to be stable in memory usage,
though, so long as you have MaxClients set low enough that your maximum
amount of committed memory is appropriate. Also, I've seen people run
other heavyweight processes, like mysql, on the same system, so that when
the volume spikes, mod_perl spikes AND mysql spikes. A sure recipe for
disaster.
[Yes, please let me know your methodology for testing this]
OK, two programs. bigshare.c:
#include stdlib.h
#include signal.h
#include unistd.h
#define MEGS 256
static char *mem = NULL;
static char vv = 0;
static void handler(int signo)
{
char val = 0;
unsigned ii;
signal(signo, handler);
for (ii=0; iiMEGS*1024*1024; ii+=4096) {
val += mem[ii];
}
vv = val;
}
int main(int argc, char **argv)
{
mem = calloc(1, MEGS*1024*1024);
fork();
fork();
signal(SIGUSR1, handler);
while(1) {
sleep(1000);
}
return 0;
}
and makeitswap.c:
#include stdlib.h
int main(int argc, char **argv)
{
char *mem = calloc(1, 384*1024*1024);
free(mem);
return 0;
}
These both compile under RedHat 7.2, you might have to adjust the #include
directives for other systems. Adjust the MEGS value in bigshare.c to be
big enough to matter, but not so big that it causes bigshare itself to
swap. I chose 1/2 of my real memory size. The 384 in makeitswap.c is 3/4
of my real memory, so it pushes tons of stuff into swap.
Run bigshare. Use ps or something appropriate to determine that, indeed,
all four bigshare processes are using up 256M of memory, but it's all
shared.
Then, run makeitswap. All of the bigshare processes should partly or
fully page out. Afterwards I I was seeing RSS from 260k to 1M on the
bigshare processes.
Then, kill -USR1 one of the bigswap processes. This causes the process to
re-read all of the memory it earlier allocated, thus it should page in
256M or so. ps or top should show the RSS rising as it swaps back in.
You can also use vmstat 1 to watch it happen (watch the Swap/si column).
On some systems you may need to use iostat. More than likely your system
response also goes to heck, because it's spending so much time
Re: Subroutines taking time to return..
Perrin Harkins wrote: You cannot reliably measure CPU clocks with wallclock on the multi-processor machine, unless you are running on Dos :) Even so, wall time is what most people actually care about, and it's fine to use if you're the only one doing work on that machine. Yes, for counting the total run-time of the code that does something. No, for benchmarking nearly-empty subroutines run times. Since the error here can be 1000% and more. You are still running on time-sharing machine and if your sub didn't fit into one CPU timeslice, but the other did, the relative difference can be tremendous, while in fact both subs consume approximately the same number of CPU clocks. This can lead to very wrong conclusions. Also search the archives, about a year ago I've posted a subclass to DBI that measures the SQL execution profiling. I'm not sure if Tim has this unctionality in the latest DBI. DBIx::Profile does a good job of this. cool :) -- _ 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: Non-web use for Apache/mod_perl
Have you tried Postgresql? It's a free, fast, ACID compliant database. I
have it compiled running within a few hours, not knowing much of anything
about it before hand. From what I've read the speed is comparable w/ mysql
for most applications.
Drew
At 12:40 AM 3/21/2002 +0100, Bas A.Schulte wrote:
To handle a large number of concurrent transactions in a transaction-safe
environment without me having to worry too much about concurrency issues
and referential integrity I will slowly move to Oracle. $dbh-do('LOCK
TABLE USER, INSTANCE, APP_DATA') just plain sucks unless you want to
create a very large distributed *single-user* system running on multiple
machines.
==
Drew Taylor JA[P|m_p]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl Hacker
mailto:[EMAIL PROTECTED] *** God bless America! ***
--
Speakeasy.net: A DSL provider with a clue. Sign up today.
http://www.speakeasy.net/refer/29655
==
Re: handler not being called
thank you all for the help.
I missed out this : PerlInitHandler Apache::StatINC
in httpd.conf.
Hence the changes I was making were not alive as the file wasnt reloaded by
mod_perl at every hit.
The thing worked when I added this line!
Riz
- Original Message -
From: Stathy G. Touloumis [EMAIL PROTECTED]
To: Rizwan Majeed [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, March 20, 2002 8:55 PM
Subject: RE: handler not being called
Can you send the code for Demo.pm?
I have added a handler entry in httpd.conf
location /myhandler
SetHandler perl-script
PerlHandler Demo
/Location
and I have printed a string inside the handler thats it.
When I do GET on the URI I get the following error.
HTML
HEADTITLEAn Error Occurred/TITLE/HEAD
BODY
H1An Error Occurred/h1
405 Method Not Allowed
/BODY
/HTML
Why isnt the handler being called. The module: Demo.pm is placed in more
than one @INC paths of perl.
Waiting for help
Riz
- Original Message -
From: Francesc Guasch Ortiz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 20, 2002 1:07 PM
Subject: Re: apache dies silently at start with perl-5.6.1 rpm
Kurt Hansen escribió:
Did you see this message from the Mason list? If so, did this
solution
not work
for you?
I installed an old Data::Dumper: Data-Dumper-2.101
Right now I have a compiled perl-5.6.1 and these apache-1.3.22-2 rpm.
Now I can start apache with the mason handler, but as soon
as I add some DBI module in the handler.pl, it doesn't work:
{ package HTML::Mason::Commands;
use DBI;
}
--
frankie
Off topic question a little worried
Hi
I found this script in one of my cgi-bin's.Not sure where it came from.
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
Can anyone tell me what it does.
Thanks
John Michael
Re: Off topic question a little worried
On Thu, 21 Mar 2002, John Michael wrote:
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
It executes arbitrary commands as whatever your httpds run as.
--
Chris Reinhardt
[EMAIL PROTECTED]
Systems Architect
Dynamic DNS Network Services
http://www.dyndns.org/
Re: Non-web use for Apache/mod_perl
Hi,
On Thursday, March 21, 2002, at 12:57 AM, Drew Taylor wrote:
Have you tried Postgresql? It's a free, fast, ACID compliant database.
I have it compiled running within a few hours, not knowing much of
anything about it before hand. From what I've read the speed is
comparable w/ mysql for most applications.
Drew
At 12:40 AM 3/21/2002 +0100, Bas A.Schulte wrote:
To handle a large number of concurrent transactions in a
transaction-safe environment without me having to worry too much about
concurrency issues and referential integrity I will slowly move to
Oracle. $dbh-do('LOCK TABLE USER, INSTANCE, APP_DATA') just plain
sucks unless you want to create a very large distributed *single-user*
system running on multiple machines.
I kinda was afraid about people getting excited about my RDBMS remarks
which really is a subject in itself ;)
I have zero personal experience with Postgresql even though I've read
good things about it so that ruled it out for a project with a very
tight time frame. And I just happen to really, really like Oracle so
unless the application generates some real money, I will probably always
go far Oracle.
Regards,
Bas.
ANNOUNCE: Embperl 2.0b7
The URL ftp://ftp.dev.ecos.de/pub/perl/embperl/Embperl-2.0b7.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GR/GRICHTER/Embperl-2.0b7.tar.gz size: 620902 bytes md5: 89b8dc62aa28684be64fd0d44857d641 Embperl is a system for building dynamic websites with Perl. See http://perl.apache.org/embperl/ (english) or http://www.ecos.de/embperl/ (german) for more information. This is mainly a bug fix release. Everybody who is using a 2.0 beta version of Embperl encouraged to upgrade. Enjoy Gerald Changes since 2.0b6: - Changed default for EMBPERL_ESCMODE from 3 to 7. This disables by default the possibilty use the backslash to not escape a piece of output. This increases the security, because it by default avoids the interpretation of the backslash in any user input that is redisplayed. - Fixed bug in mail syntax and Embperl::Mail reported by Jan Kyncl. - Removed LogFormat and CustsomLog from test config, so mod_log_config is not required for make test. Reported by Jochen Topf. - Removed EmbperlObject.pm from MANIFEST, since it was replaced by Embperl/Object.pm. - Make symbolsnames unique so they don't clash with 1.3.4. Reported by Kee Hinckley. - Fixed a problem that ocurred when a reference to some of the Embperl objects was kept after the end of it's lifetime, which caused a segfault. - Don't do a path search when the filename starts with './'. - Fixed a segfault that occured when many nested sub's are used, but only a low number of strings. - Fixed a problem that option tags are not correctly selected, when the option tag was inside a loop and the name of the select tag was dynamicly generated. - Added test for config directives inside of VirtualHost - 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: ANNOUNCE: Embperl 2.0b7
Any idea when 2.0-STABLE is going to come out? I think the main issuses with the code are solved, so it's stable to use right now, also I want to give people some more time for testing. The main work to do before the stable release is to write better documentation. To transform all the quick notes in README.v2 into real docs. I can't promise anything, but I hope to get it out during the next few months. Gerald - 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 -
cvs commit: modperl-site/embperl index.html
richter 02/03/20 22:58:08 Modified:embperl index.html Log: Embperl Webpages - Changes Revision ChangesPath 1.132 +1 -1 modperl-site/embperl/index.html Index: index.html === RCS file: /home/cvs/modperl-site/embperl/index.html,v retrieving revision 1.131 retrieving revision 1.132 diff -u -r1.131 -r1.132 --- index.html21 Mar 2002 06:49:57 - 1.131 +++ index.html21 Mar 2002 06:58:08 - 1.132 @@ -71,7 +71,7 @@ tr td bgcolor=#AFBDCAnbsp;Current Versionbr nbsp;a href=Embperl.pod.16.htmlcodeStable: 1.3.4/code/abr - nbsp;a href=Embperl.pod.16.htmlcodeBeta: nbsp;nbsp;2.0b6/code/abr + nbsp;a href=Embperl.pod.16.htmlcodeBeta: nbsp;nbsp;2.0b7/code/abr /tr tr td bgcolor=#00 align=centerbiga href=http://www.ecos.de/embperl/;img src=de.gif border=0/a/big/td @@ -247,7 +247,7 @@ blockquote pfont color=#808080 size=1hr HTML::Embperl - Copyright (c) 1997-2001 Gerald Richter / ECOS lt;[EMAIL PROTECTED]gt; - Last Update $Id: index.html,v 1.131 2002/03/21 06:49:57 richter Exp $/font/p + Last Update $Id: index.html,v 1.132 2002/03/21 06:58:08 richter Exp $/font/p /blockquote /td/tr!--msnavigation--/table/body /html
