Re: Advanced daemon allocation
At 02:29 PM 6/18/2001 +0800, Trevor Phillips wrote: >Gunther Birznieks wrote: > > >I suppose I could do this now by having a front-end proxy, and mini-Apache > > >configs for each "group" I want, but that seems to be going too far > (at this > > >stage), especially if the functionality already exists to do this > within the > > >one server. > >To me, this isn't very ideal. Even sharing most of an apache configuration >file, what is the overhead of running a separate server? And can multiple I think this is covered in the guide. >Apache servers share writing to the same log files? Why would you need to? The front end can write the log file. Then don't bother logging the mod_perl servers. Or make them all log to syslog or some other shared logging mechanism. >It also doesn't help if I have dozens of possible groupings - running >dozens of >slightly different Apache's doesn't seem a clean solution. Hence me asking if >it was possible within the one Apache server to prioritise the allocation to >specific daemons, based on some criteria, which would be a more efficient and >dynamic solution, if it's possible. It's not ideal, but it's also not possible to do what you say until mod_perl 2.0. You might also consider using Speedy::CGI if you aren't using handlers as it makes the multiple configs issue much more trivial to administer, but you still get a pretty fast speed up.
Re: Advanced daemon allocation
Gunther Birznieks wrote: > > Yeah, just use the mod_proxy model and then proxy to different mod_perl > backend servers based on the URL itself. Isn't this pretty much what I said is *a* solution? > >I suppose I could do this now by having a front-end proxy, and mini-Apache > >configs for each "group" I want, but that seems to be going too far (at this > >stage), especially if the functionality already exists to do this within the > >one server. To me, this isn't very ideal. Even sharing most of an apache configuration file, what is the overhead of running a separate server? And can multiple Apache servers share writing to the same log files? It also doesn't help if I have dozens of possible groupings - running dozens of slightly different Apache's doesn't seem a clean solution. Hence me asking if it was possible within the one Apache server to prioritise the allocation to specific daemons, based on some criteria, which would be a more efficient and dynamic solution, if it's possible. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : CWIS Systems Administrator - [EMAIL PROTECTED] : | IT Services - Murdoch University | >--- Member of the #SAS# & #CFC# < | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: Advanced daemon allocation
On Mon, 18 Jun 2001, Trevor Phillips wrote: > Is there any way to control which daemon handles a certain request with apache > 1.x? http://perl.apache.org/guide/strategy.html#Running_More_than_One_mod_perl_S > eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl > application to 10 specific daemons would improve the efficiency of data cached > in those processes. > > If this is impossible in Apache 1.x, will it be possible in 2.x? I can really > see a more advanced model for allocation improving efficiency and performance. > Even if it isn't a hard-limit, but a preferential arrangement where, for > example, hits to a particular URL tend to go to the same daemon(s), this would > improve the efficiency of data cached within the daemon. > > I suppose I could do this now by having a front-end proxy, and mini-Apache > configs for each "group" I want, but that seems to be going too far (at this > stage), especially if the functionality already exists to do this within the > one server. > > -- > . Trevor Phillips - http://jurai.murdoch.edu.au/ . > : CWIS Systems Administrator - [EMAIL PROTECTED] : > | IT Services - Murdoch University | > >--- Member of the #SAS# & #CFC# < > | On nights such as this, evil deeds are done. And good deeds, of / > | course. But mostly evil, on the whole. / > \ -- (Terry Pratchett, Wyrd Sisters) / > _ 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: Advanced daemon allocation
Yeah, just use the mod_proxy model and then proxy to different mod_perl backend servers based on the URL itself. At 01:17 PM 6/18/2001 +0800, Trevor Phillips wrote: >Is there any way to control which daemon handles a certain request with apache >1.x? > >eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl >application to 10 specific daemons would improve the efficiency of data cached >in those processes. > >If this is impossible in Apache 1.x, will it be possible in 2.x? I can really >see a more advanced model for allocation improving efficiency and performance. >Even if it isn't a hard-limit, but a preferential arrangement where, for >example, hits to a particular URL tend to go to the same daemon(s), this would >improve the efficiency of data cached within the daemon. > >I suppose I could do this now by having a front-end proxy, and mini-Apache >configs for each "group" I want, but that seems to be going too far (at this >stage), especially if the functionality already exists to do this within the >one server. > >-- >. Trevor Phillips - http://jurai.murdoch.edu.au/ . >: CWIS Systems Administrator - [EMAIL PROTECTED] : >| IT Services - Murdoch University | > >--- Member of the #SAS# & #CFC# < >| On nights such as this, evil deeds are done. And good deeds, of / >| course. But mostly evil, on the whole. / > \ -- (Terry Pratchett, Wyrd Sisters) / __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Advanced daemon allocation
Is there any way to control which daemon handles a certain request with apache 1.x? eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl application to 10 specific daemons would improve the efficiency of data cached in those processes. If this is impossible in Apache 1.x, will it be possible in 2.x? I can really see a more advanced model for allocation improving efficiency and performance. Even if it isn't a hard-limit, but a preferential arrangement where, for example, hits to a particular URL tend to go to the same daemon(s), this would improve the efficiency of data cached within the daemon. I suppose I could do this now by having a front-end proxy, and mini-Apache configs for each "group" I want, but that seems to be going too far (at this stage), especially if the functionality already exists to do this within the one server. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : CWIS Systems Administrator - [EMAIL PROTECTED] : | IT Services - Murdoch University | >--- Member of the #SAS# & #CFC# < | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: CGI::Cookie vs Apache::Cookie -- help?
- Original Message -
From: "will trillich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 18, 2001 7:09 AM
Subject: Re: CGI::Cookie vs Apache::Cookie -- help?
> On Sun, Jun 17, 2001 at 11:14:23PM -0400, Chris Winters wrote:
> > * will trillich ([EMAIL PROTECTED]) [010617 23:04]:
> > > $r->log_error( qq(...id=$ID, sending cookie) );
>
> --this outputs the string i'm hoping for, into the log file.
That's because you're outputting $ID and not the cookie itself, which you're
creating below.
>
> > > my $cookie =
> > > Apache::Cookie->new( $r,
> > > -name => $cookie_name,
> > > -value => $ID ,
> > > -domain => $r->hostname,
> > > -path => '/' ,
> > > );
> > > $r->header_out('Set-Cookie', => $cookie);
>
> > From 'perldoc Apache::Cookie'
> >
> >bake
> >Put cookie in the oven to bake. (Add a Set-Cookie
> >header to the outgoing headers table.)
> >
> >$cookie->bake;
>
> what does $cookie->bake do (add set-cookie header) that
> $r->header_out('set-cookie'=>$cookie) (add set-cookie header)
> does not?
>
> [ and why ain't that mentioned in the manual? ]
As someone else stated, bake() actually sends a Set-Cookie header, but with
$cookie->as_string and not just $cookie (which is an instance of
Apache::Cookie). When you're just sending $cookie you're sending an object
reference.
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: CGI::Cookie vs Apache::Cookie -- help?
On Sun, Jun 17, 2001 at 11:14:23PM -0400, Chris Winters wrote:
> * will trillich ([EMAIL PROTECTED]) [010617 23:04]:
> > $r->log_error( qq(...id=$ID, sending cookie) );
--this outputs the string i'm hoping for, into the log file.
> > my $cookie =
> > Apache::Cookie->new( $r,
> > -name => $cookie_name,
> > -value => $ID ,
> > -domain => $r->hostname,
> > -path => '/' ,
> > );
> > $r->header_out('Set-Cookie', => $cookie);
> From 'perldoc Apache::Cookie'
>
>bake
>Put cookie in the oven to bake. (Add a Set-Cookie
>header to the outgoing headers table.)
>
>$cookie->bake;
what does $cookie->bake do (add set-cookie header) that
$r->header_out('set-cookie'=>$cookie) (add set-cookie header)
does not?
[ and why ain't that mentioned in the manual? ]
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: [OT] Is this feasible in Perl??
On Wed, Jun 13, 2001 at 06:57:45AM +0800, Gunther Birznieks wrote: > My experience is that architecturally Perl cannot handle this. You should > switch to Java and use an Enterprise Java Bean to do all this for you. you must have an interesting sense of humor. -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: CGI::Cookie vs Apache::Cookie -- help?
On Sun, 17 Jun 2001, will trillich wrote:
> $r->log_error( qq(...id=$ID, sending cookie) );
> my $cookie =
> Apache::Cookie->new( $r,
> -name => $cookie_name,
> -value => $ID ,
> -domain => $r->hostname,
> -path => '/' ,
> );
> $r->header_out('Set-Cookie', => $cookie);
You forgot to bake your cookie... Read the Apache::Cookie docs again.
Get rid of the $r->header_out(...) line and use the following instead.
$cookie->bake();
Cees
Re: CGI::Cookie vs Apache::Cookie -- help?
* will trillich ([EMAIL PROTECTED]) [010617 23:04]:
> mine is similar:
>
> $r->log_error( qq(...id=$ID, sending cookie) );
> my $cookie =
> Apache::Cookie->new( $r,
> -name => $cookie_name,
> -value => $ID ,
> -domain => $r->hostname,
> -path => '/' ,
> );
> $r->header_out('Set-Cookie', => $cookie);
>
> which sets a cookie value of "SCALAR(0x863c9f8)" instead of the
> $ID string that shows up in the log, which is
>
> ...id=483dd0e2202accce6d4d3e07d976bfdc, sending cookie
>
> in the original ticket example above, -value is a hashref:
>
> -value => { ID => $ID }
>
> instead of
>
> -value => $ID
>
> as the Apache::Cookie manpage suggests (a plain scalar value).
>
> this worked just fine with CGI::Cookie (without the $r, of
> course) -- can't get it to return the actual scalar value with
> Apache::Cookie...
>
> ideas? help!
>From 'perldoc Apache::Cookie'
bake
Put cookie in the oven to bake. (Add a Set-Cookie
header to the outgoing headers table.)
$cookie->bake;
as_string
Format the cookie object as a string:
#same as $cookie->bake
$r->err_headers_out->add("Set-Cookie" => $cookie->as_string);
HTH
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: mod_perl DSO leaking on restart?
Now I'm really confused. I built the whole thing statically and it still leaks: the static build (using the same Perl): ~/test/prefix/bin/perl Makefile.PL EVERYTHING=1 \ APACHE_PREFIX=$(echo ~/test/prefix/apache) \ APACHE_SRC=../apache_1.3.19 DO_HTTPD=1 Now it still leaks 520K per restart: > make start_httpd_fork ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t > ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 7856 httpd > kill -USR1 $(cat t/logs/httpd.pid ) > ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 8488 httpd > kill -USR1 $(cat t/logs/httpd.pid ) > ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 9108 httpd This is on Redhat 7.1 (not Linux 7.1 as I said below). I didn't bother trying it on Solaris. You don't suppose building with APACHE_PREFIX could have anything to do with it, do you? I haven't heard of any leaks with a static build. -P On Sun, 17 Jun 2001, Paul G. Weiss wrote: > Doug, > > I'm confused as to how you managed to *not* leak when I'm still > leaking. I've tried these tests on both a Solaris 2.7 system and > a Linux 7.1. > > Here is a summary of what I do: > > I build Perl > > ./Configure -des -Uusemymalloc -Dprefix=$(echo ~/test/prefix) -Dcc=gcc > make && make test && make install > > I build Apache > > ~/test/prefix/bin/perl Makefile.PL USE_DSO=1 EVERYTHING=1 \ > USE_APACI=1 APACHE_PREFIX=$(echo ~/test/prefix/apache) \ > APACHE_SRC=../apache_1.3.19 \ > APACI_ARGS='--enable-module=all --enable-shared=max' \ > DO_HTTPD=1 > > make > make test > > I now run the test: > > make start_httpd_fork > ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) > kill -USR1 $(cat t/logs/httpd.pid ) > ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) > kill -USR1 $(cat t/logs/httpd.pid ) > > etc. The virtual size grows each time, although by different amounts > in Linux and Solaris. Both are around 4Mb. So what are you doing > differently? Let me know so I can do the same thing. The Perl I'm using > is 5.6.1 and the modperl is > modperl_20010614113010.tar.gz. > > -P > > > On Fri, 15 Jun 2001, Paul G. Weiss wrote: > > > Don't be so willing to bet. Still leaking. > > > > I did as you said and just rebuilt Perl and mod_perl but didn't bother to > > rebuild all the Perl modules (I would have done so had I been successful > > here). > > > > Here's what I see: > > > > > make start_httpd_fork > > ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t > > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > > PID PPID VSZ COMMAND > > 28802 1 15528 ../apache_1.3.19/src/httpd > > > kill -USR1 $(cat t/logs/httpd.pid ) > > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > > PID PPID VSZ COMMAND > > 28802 1 20016 ../apache_1.3.19/src/httpd > > > kill -USR1 $(cat t/logs/httpd.pid ) > > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > > PID PPID VSZ COMMAND > > 28802 1 24544 ../apache_1.3.19/src/httpd > > > kill -USR1 $(cat t/logs/httpd.pid ) > > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > > PID PPID VSZ COMMAND > > 28802 1 27224 ../apache_1.3.19/src/httpd > > > make kill_httpd > > kill `cat t/logs/httpd.pid` > > rm -f t/logs/httpd.pid > > rm -f t/logs/error_log > > > > > > > > On Thu, 14 Jun 2001, Doug MacEachern wrote: > > > > > On Fri, 15 Jun 2001, Paul G. Weiss wrote: > > > > > > > alignbytes=8, usemymalloc=y, prototype=define > > > ^ > > > ok, here's why i kept asking for perl -V. i don't see Perl's malloc.c > > > ever release its memory pool. when usemymalloc=y, free() only puts memory > > > back into Perl's pool for use by other malloc()'s. i don't see a function > > > to destroy this pool when perl cleans itself up. willing to bet if you > > > rebuild Perl with: Configure -des -Uusemymalloc ... > > > and then rebuild mod_perl, the leaks will go away. > > > > > > > > > >
CGI::Cookie vs Apache::Cookie -- help?
On Sat, Jun 16, 2001 at 12:58:14AM +0200, Nenad wrote:
> package Apache::PermanentTicketRenewer
> my Counter;
> sub handler {
> my $r = shift;
>
> $Counter += 1;
> my $cookie = CGI::Cookie->new(-name => 'Ticket',
> -path => '/',
> -domain => '.my.com',
> -expires => '+1M',
> -value => { 'ID' => $Counter }
>);
mine is similar:
$r->log_error( qq(...id=$ID, sending cookie) );
my $cookie =
Apache::Cookie->new( $r,
-name => $cookie_name,
-value => $ID ,
-domain => $r->hostname,
-path => '/' ,
);
$r->header_out('Set-Cookie', => $cookie);
which sets a cookie value of "SCALAR(0x863c9f8)" instead of the
$ID string that shows up in the log, which is
...id=483dd0e2202accce6d4d3e07d976bfdc, sending cookie
in the original ticket example above, -value is a hashref:
-value => { ID => $ID }
instead of
-value => $ID
as the Apache::Cookie manpage suggests (a plain scalar value).
this worked just fine with CGI::Cookie (without the $r, of
course) -- can't get it to return the actual scalar value with
Apache::Cookie...
ideas? help!
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: mod_perl DSO leaking on restart?
Doug, I'm confused as to how you managed to *not* leak when I'm still leaking. I've tried these tests on both a Solaris 2.7 system and a Linux 7.1. Here is a summary of what I do: I build Perl ./Configure -des -Uusemymalloc -Dprefix=$(echo ~/test/prefix) -Dcc=gcc make && make test && make install I build Apache ~/test/prefix/bin/perl Makefile.PL USE_DSO=1 EVERYTHING=1 \ USE_APACI=1 APACHE_PREFIX=$(echo ~/test/prefix/apache) \ APACHE_SRC=../apache_1.3.19 \ APACI_ARGS='--enable-module=all --enable-shared=max' \ DO_HTTPD=1 make make test I now run the test: make start_httpd_fork ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) etc. The virtual size grows each time, although by different amounts in Linux and Solaris. Both are around 4Mb. So what are you doing differently? Let me know so I can do the same thing. The Perl I'm using is 5.6.1 and the modperl is modperl_20010614113010.tar.gz. -P On Fri, 15 Jun 2001, Paul G. Weiss wrote: > Don't be so willing to bet. Still leaking. > > I did as you said and just rebuilt Perl and mod_perl but didn't bother to > rebuild all the Perl modules (I would have done so had I been successful > here). > > Here's what I see: > > > make start_httpd_fork > ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > PID PPID VSZ COMMAND > 28802 1 15528 ../apache_1.3.19/src/httpd > > kill -USR1 $(cat t/logs/httpd.pid ) > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > PID PPID VSZ COMMAND > 28802 1 20016 ../apache_1.3.19/src/httpd > > kill -USR1 $(cat t/logs/httpd.pid ) > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > PID PPID VSZ COMMAND > 28802 1 24544 ../apache_1.3.19/src/httpd > > kill -USR1 $(cat t/logs/httpd.pid ) > > ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) > PID PPID VSZ COMMAND > 28802 1 27224 ../apache_1.3.19/src/httpd > > make kill_httpd > kill `cat t/logs/httpd.pid` > rm -f t/logs/httpd.pid > rm -f t/logs/error_log > > > > On Thu, 14 Jun 2001, Doug MacEachern wrote: > > > On Fri, 15 Jun 2001, Paul G. Weiss wrote: > > > > > alignbytes=8, usemymalloc=y, prototype=define > > ^ > > ok, here's why i kept asking for perl -V. i don't see Perl's malloc.c > > ever release its memory pool. when usemymalloc=y, free() only puts memory > > back into Perl's pool for use by other malloc()'s. i don't see a function > > to destroy this pool when perl cleans itself up. willing to bet if you > > rebuild Perl with: Configure -des -Uusemymalloc ... > > and then rebuild mod_perl, the leaks will go away. > > >
Re: Capturing CGI output
From: "Steve Wells" <[EMAIL PROTECTED]>
> I can use $r->lookup_uri('/cgifile.cgi') to gather up the subrequest and
> run it using the run() command. However, the information from the CGI
> is passed back to the browser instead of handed off to me for
> processing. Is there some way to capture that information?
You could use LWP to make the request instead of using a subrequest, or you
could use a modified version of Apache::PerlRun or Apache::Registry that
fakes CGI and captures the output. You can look at Apache::Filter for some
ideas.
- Perrin
Capturing CGI output
I have a mod_perl library that utilizes the Tempate Toolkit so that html
files are parsed through the toolkit before being sent back to the
browser. It works great but now they require that the library be
upgraded to include support for CGI's. In other words I need to capture
the output of the CGI as though it were a template and parse it as well.
I can use $r->lookup_uri('/cgifile.cgi') to gather up the subrequest and
run it using the run() command. However, the information from the CGI
is passed back to the browser instead of handed off to me for
processing. Is there some way to capture that information?
Thanks,
STEVE
RE: Make Test problems...
in this case delete the old error_log file before you start the test, you have all the mess from the previous run posted. > /home/ian/mod_perl-1.25/t/logs/httpd.pid overwritten -- Unclean shutdown of > previous Apache run? It looks like it starts here: > [notice] Destruction->DESTROY called for $global_object > [Sun Jun 17 02:57:55 2001] [warn] [notice] child_init for process 2497, > report any problems to [no address given] what happens when you run: ../apache_1.3.9/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & Do you get a core file dumped? I have missed the original problem post. Is this a static build or DSO? What 'perl -V' says? _ 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/
