This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
====
Subject: RE: [ANNOUNCE] Apache::Reload 0.04
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 30 Aug 2000 20:28:41 +0100 (BST)
On Wed, 30 Aug 2000, Stas Bekman wrote:
> On Wed, 30 Aug 2000, Matt Sergeant wrote:
>
> > On Wed, 30 Aug 2000, Douglas Wilson wrote:
> >
> > > Forgive me if this is a stupid question, but I am rather
> > > ignorant in regards to mod_perl, and I'm curious about
> > > something.
> > >
> > > If you reload modules, does that increase the size of the
> > > forked children of the parent process? Or does just the
> > > parent reload, with the children having to die and respawn?
> >
> > It increases the size - you lose shared memory. But only on modules that
> > actually get reloaded.
> >
> > > Or do we care? :)
>
> We care a lot.
> http://perl.apache.org/guide/performance.html#Sharing_Memory
>
> But only in production. This module is used mostly for the development.
This module is actually designed so that it makes reasonable sense in
production too. The touch file thing makes sure that you can update
modules and make them live before you have scheduled downtime. I think
that's very useful for a live server, even if it does use a bit more RAM.
===
Subject: RE: [ANNOUNCE] Apache::Reload 0.04
From: Stas Bekman <stas@stason.org>
Date: Wed, 30 Aug 2000 21:35:27 +0200 (CEST)
On Wed, 30 Aug 2000, Matt Sergeant wrote:
> On Wed, 30 Aug 2000, Stas Bekman wrote:
>
> > On Wed, 30 Aug 2000, Matt Sergeant wrote:
> >
> > > On Wed, 30 Aug 2000, Douglas Wilson wrote:
> > >
> > > > Forgive me if this is a stupid question, but I am rather
> > > > ignorant in regards to mod_perl, and I'm curious about
> > > > something.
> > > >
> > > > If you reload modules, does that increase the size of the
> > > > forked children of the parent process? Or does just the
> > > > parent reload, with the children having to die and respawn?
> > >
> > > It increases the size - you lose shared memory. But only on modules that
> > > actually get reloaded.
> > >
> > > > Or do we care? :)
> >
> > We care a lot.
> > http://perl.apache.org/guide/performance.html#Sharing_Memory
> >
> > But only in production. This module is used mostly for the development.
>
> This module is actually designed so that it makes reasonable sense in
> production too. The touch file thing makes sure that you can update
> modules and make them live before you have scheduled downtime. I think
> that's very useful for a live server, even if it does use a bit more RAM.
But adds an additional stat() call for each request, which might be not
desired for "some" sites... I know it's quite fast. See:
http://thingy.kcilink.com/modperlguide/performance/Reducing_the_Number_of_stat_Ca.html
But, yeah it's cool!
===
Subject: Re: Apache::Reload 0.04
From: Greg Stark <gsstark@mit.edu>
Date: 01 Sep 2000 22:16:48 -0400
Stas Bekman <stas@stason.org> writes:
> But adds an additional stat() call for each request, which might be not
> desired for "some" sites... I know it's quite fast. See:
> http://thingy.kcilink.com/modperlguide/performance/Reducing_the_Number_of_stat_Ca.html
>
> But, yeah it's cool!
In practice I find that stat calls are a minor performance factor when
compared with database calls so for any fairly dynamic site it's not a big
factor.
However, perhaps a better tradeoff for a production site would be to perform
these stat calls in the parent just before a graceful restart. Then to force
rereading the library files without any downtime the you would just do a
graceful restart, which would recompile all the .pm files and then start
spawning new children with optimal shared memory behaviour:)
I believe Apache::ASP's internal mechanism is capable of this now.
===
Subject: Re: Apache::Reload 0.04
From: Stas Bekman <stas@stason.org>
Date: Sat, 2 Sep 2000 11:39:07 +0200 (CEST)
Stas Bekman <stas@stason.org> writes:
>
> > But adds an additional stat() call for each request, which might be not
> > desired for "some" sites... I know it's quite fast. See:
> > http://thingy.kcilink.com/modperlguide/performance/Reducing_the_Number_of_stat_Ca.html
> >
> > But, yeah it's cool!
>
> In practice I find that stat calls are a minor performance factor when
> compared with database calls so for any fairly dynamic site it's not a big
> factor.
>
> However, perhaps a better tradeoff for a production site would be to perform
> these stat calls in the parent just before a graceful restart. Then to force
> rereading the library files without any downtime the you would just do a
> graceful restart, which would recompile all the .pm files and then start
> spawning new children with optimal shared memory behaviour:)
>
> I believe Apache::ASP's internal mechanism is capable of this now.
That's what PerlFreshRestart was written for. But as the current state
goes it's deprecated since many people has reported segfaults with it (at
least for those who has this problem). Otherwise it does just like what
you have described above, without any relation to Apache::Reload.
===
Subject: Re: Apache::Reload 0.04
From: Joshua Chamas <joshua@chamas.com>
Date: Sat, 02 Sep 2000 16:38:51 -0700
Greg Stark wrote:
>
> Stas Bekman <stas@stason.org> writes:
>
> > But adds an additional stat() call for each request, which might be not
> > desired for "some" sites... I know it's quite fast. See:
> > http://thingy.kcilink.com/modperlguide/performance/Reducing_the_Number_of_stat_Ca.html
> >
> > But, yeah it's cool!
>
> In practice I find that stat calls are a minor performance factor when
> compared with database calls so for any fairly dynamic site it's not a big
> factor.
>
> However, perhaps a better tradeoff for a production site would be to perform
> these stat calls in the parent just before a graceful restart. Then to force
> rereading the library files without any downtime the you would just do a
> graceful restart, which would recompile all the .pm files and then start
> spawning new children with optimal shared memory behaviour:)
>
> I believe Apache::ASP's internal mechanism is capable of this now.
>
Yes, to have Apache::ASP reload scripts and libraries just at
restart, for normal scripts config do:
PerlSetVar StatScripts 0
PerlSetVar StatINC 0 # default
Then for a perl restart handler, register a sub which
calls Loader()
sub restart {
Apache::ASP->Loader(
'/path/to/scripts/', '\.asp$|$other_pattern_match'
StatINC => 1,
%OtherConfigs
);
}
This will make your web site only change upon server
graceful restart, and saves some stat() calls.
The StatINC mechanism is similar to what is provided
by Apache::Reload and Apache::StatINC.
Note that I would not use this method much, as the
restart handler last I checked seems to leak 1M RAM
for each graceful, but this is a nicer way to republish
your web site than doing a hard stop/start
===
Subject: [ANNOUNCE] Apache::Reload 0.05
From: Matt Sergeant <matt@sergeant.org>
Date: Mon, 4 Sep 2000 10:12:07 +0100 (BST)
This latest release of Reload adds the ability to specify an entire
hierarchy of modules in the ReloadModules list, like so:
PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"
which will reload all modules from Foo/Bar.pm to Foo/Bar/Blue/Far/Gear.pm
and so on.
===
Subject: reload
From: test@blackhole.acon.nl
Date: Wed, 6 Sep 2000 11:31:05 +0200 (CEST)
I thought Reload would be quite helpfull because of not having to restart
the server, but now I am quite stuck. Only the first form shows all the
changes immediately. The second form after pushing a button does not.
Is this explainable?
Arnold
perl.conf starting:
PerlRequire conf/startup.pl
PerlFreshRestart On
PerlPostReadRequestHandler 'sub { Apache->request(shift) } '
PerlTransHandler Apache::StripSession
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll off
package Myapp.pm
use strict;
use Apache::Constants qw(:common);
use Apache::File ();
use CGI qw(:standard :html3 :netscape);
use Image::Magick ();
use DBI ();
use Apache::Reload;
handler {
CASE: {
/^/i and do some_other_form()
first_form();
}
}
sub first_form() {
This form does show changes for all children.
Push a submit button to go some_other_form
}
sub some_other_form() {
This form does not show changes at all..
}
===
Subject: OT: Server-push client page reload
From: Michael Nachbaur <MNachba@rei.com>
Date: Wed, 20 Sep 2000 13:43:40 -0700
This is off-topic, but I need an answer pretty quick, and I
*am* writing this app using mod_perl, so its sorta related
(also, I don't want the headache of re-subscribing to a new
list).
You know those online web-based tech support chat systems?
Its commonly frame based, but its just like IRC, but over
HTML. when a user posts a message it immediatly pops up on
the chat frame, and you submit your message through a
regular-ol' HTML form. I don't think this is an applet,
because this works in all sorts of browsers. I think its
javascript, but I'm not sure. My main question, is when the
server knows that a new message has been posted, how does it
push that new page out to the client web browser? I'm used
to all page-views originating from the client...not the
server.
===
Subject: Re: OT: Server-push client page reload
From: Craig McLane <cmclane@citysearch.com>
Date: Wed, 20 Sep 2000 13:55:02 -0700 (PDT)
I believe they are using meta refresh tags in the html to refresh the page
on a regular interval.
Craig
On Wed, 20 Sep 2000, Michael Nachbaur wrote:
> This is off-topic, but I need an answer pretty quick, and
> I *am* writing this app using mod_perl, so its sorta
> related (also, I don't want the headache of re-subscribing
> to a new list).
You know those online web-based tech support chat systems?
Its commonly frame based, but its just like IRC, but over
HTML. when a user posts a message it immediatly pops up on
the chat frame, and you submit your message through a
regular-ol' HTML form. I don't think this is an applet,
because this works in all sorts of browsers. I think its
javascript, but I'm not sure. My main question, is when the
server knows that a new message has been posted, how does it
push that new page out to the client web browser? I'm used
to all page-views originating from the client...not the
server.
===
Subject: Re: OT: Server-push client page reload
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 20 Sep 2000 21:58:24 +0100 (BST)
On Wed, 20 Sep 2000, Michael Nachbaur wrote:
> This is off-topic, but I need an answer pretty quick, and I *am*
> writing this app using mod_perl, so its sorta related (also, I don't
> want the headache of re-subscribing to a new list).
>
> You know those online web-based tech support chat systems? Its
> commonly frame based, but its just like IRC, but over HTML. when a
> user posts a message it immediatly pops up on the chat frame, and you
> submit your message through a regular-ol' HTML form. I don't think
> this is an applet, because this works in all sorts of browsers. I
> think its javascript, but I'm not sure. My main question, is when the
> server knows that a new message has been posted, how does it push that
> new page out to the client web browser? I'm used to all page-views
> originating from the client...not the server.
Plain old meta refreshes. Usually every 5 or 10 seconds or so. Perhaps
configurable on a user and/or server basis.
===
Subject: Re: OT: Server-push client page reload
From: ___cliff rayman___ <cliff@genwax.com>
Date: Wed, 20 Sep 2000 14:49:47 -0700
Ime Smits wrote:
> | Plain old meta refreshes. Usually every 5 or 10 seconds or so. Perhaps
> | configurable on a user and/or server basis.
>
> You could make it even more smooth by doing a multipart document (aka server
> push): finishing a HTML document but not closing the HTTP connection and
> start a new document as soon as someone else drops a line. But that is a
> terrible thing to do in mod_perl, because each client will occupy an Apache
> process as long as he's connected. Writing a simple http daemon handling the
> chatbox on another port wouldn't be that complicated, and there are modules
> out there. Take a look at Apprentice, a realy slim httpd written in threaded
> perl, I'm sure it's somewhere on freshmeat.
i think that this technique works with netscape but not with
IE. on IE you have to set-up channels.
===
Subject: Re: OT: Server-push client page reload
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 20 Sep 2000 22:53:46 +0100 (BST)
On Wed, 20 Sep 2000, Ime Smits wrote:
> | Plain old meta refreshes. Usually every 5 or 10 seconds or so. Perhaps
> | configurable on a user and/or server basis.
>
> You could make it even more smooth by doing a multipart document (aka server
> push): finishing a HTML document but not closing the HTTP connection and
> start a new document as soon as someone else drops a line. But that is a
> terrible thing to do in mod_perl, because each client will occupy an Apache
> process as long as he's connected. Writing a simple http daemon handling the
> chatbox on another port wouldn't be that complicated, and there are modules
> out there. Take a look at Apprentice, a realy slim httpd written in threaded
> perl, I'm sure it's somewhere on freshmeat.
I was under the impression that internet explorer dropped support for
server push...
===
Subject: Re: OT: Server-push client page reload
From: "Ime Smits" <ime@iae.nl>
Date: Thu, 21 Sep 2000 00:27:52 +0200
I was under the impression that internet explorer dropped support for
| server push...
OK, didn't know that. We should probably lawsuit them for telling us
"Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" then ;)
===
Subject: Re: OT: Server-push client page reload
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 20 Sep 2000 18:12:41 -0700
Michael" == Michael Nachbaur <MNachba@rei.com> writes:
Michael> This is off-topic, but I need an answer pretty quick, and I
Michael> *am* writing this app using mod_perl, so its sorta related
Michael> (also, I don't want the headache of re-subscribing to a new
Michael> list).
Michael> You know those online web-based tech support chat systems?
Michael> Its commonly frame based, but its just like IRC, but over
Michael> HTML. when a user posts a message it immediatly pops up on
Michael> the chat frame, and you submit your message through a
Michael> regular-ol' HTML form. I don't think this is an applet,
Michael> because this works in all sorts of browsers. I think its
Michael> javascript, but I'm not sure. My main question, is when the
Michael> server knows that a new message has been posted, how does it
Michael> push that new page out to the client web browser? I'm used
Michael> to all page-views originating from the client...not the
Michael> server.
Michael> Any ideas?
Server push is not universal. Client Pull is more available.
See <http://www.perlmonks.org/index.pl?node_id=31083> for an example
of a very short client-pull webchat, from an upcoming WebTechniques
column (past columns at <http://www.stonehenge.com/merlyn/WebTechniques/>).
===
Subject: Re: OT: Server-push client page reload
From: <test@blackhole.acon.nl>
Date: Thu, 21 Sep 2000 19:45:08 +0200 (CEST)
type: multipart/x-mixed-replace
use CGI::Push qw(:standard)
do_push(-next_page=>\&draw_a_page)
sub draw_a_page {
my ($q,$counter)= @_;
return undef if $counter >100;
my $time = localtime();
return start)html(),
h1('test'),
'This page is caaled $counter times',
hr,
$time,
end_html;
}
This is what I used once just as a test , but not under mod_perl.
Netscape does support it. I understand that you have to set up channels
under MS.. Not any idea about that. Could somebody point me some
direction regarding channels.
===
Subject: Re: OT: Server-push client page reload
From: Roger Espel Llima <espel@iagora.net>
Date: Fri, 22 Sep 2000 11:20:57 +0200
Michael Nachbaur asked:
> This is off-topic, but I need an answer pretty quick, and I *am*
> writing this app using mod_perl, so its sorta related (also, I don't
> want the headache of re-subscribing to a new list).
>
> You know those online web-based tech support chat systems? Its
> commonly frame based, but its just like IRC, but over HTML. when a
> user posts a message it immediatly pops up on the chat frame, and you
> submit your message through a regular-ol' HTML form. I don't think
> this is an applet, because this works in all sorts of browsers. I
> think its javascript, but I'm not sure. My main question, is when the
> server knows that a new message has been posted, how does it push that
> new page out to the client web browser? I'm used to all page-views
> originating from the client...not the server.
The two "regular" answers are meta refresh and server push. But meta
refresh is clunky and server push apparently doesn't work well with IE.
When I had to implement this, I found a third option that experimentally
seems to work quite well: just keep the connection open and send the
messages as they are generated. Since major browsers show webpages
incrementally, you'll get much smoother display than with meta refresh.
The remaining problem is to get the browser to scroll down, but you can
do that with javascript.
And for clients where that doesn't work, there's always meta refresh.
OTOH, you probably don't want to do that with Apache and mod_perl, for
two reasons: 1) keeping an appache process per long-term client is
hugely wasteful, and 2) multiple processes are a lousy way to implement
a chat backend, because they need to notify each other of new messages.
===