Re: Terminating Child process Dynamically (and keeping huge amounts of data in RAM)

[Randolf Richardson <ra...@modperl.pl>]

> Bouncing means restart the application to bring the current changes and new
> data to the cache. We can't use the following logic as there are huge
> number of existing data cache and perl modules involved.  So the changes
> will be massive.

	Keeping code in RAM is fine (that's one of the points of mod_perl 
and mod_perl2 -- to keep the compiled version available for immediate 
use, hence this can, and often does as I've observed, yield shorter 
response times than serving non-dynamic HTML files from disk).

	Keeping small amounts of data in RAM is also fine, but keeping huge 
amounts seems unusual.  I'm currently working on a web site that has 
data stored in PostgreSQL, for which my mod_perl2 code will 
effectively generate more than 2.6 million web pages (user-driven 
activity will gradually cause this to increase); although I suppose I 
could load all this data in RAM on a server with 32 GBs of RAM (the 
database consumes nearly 20 GBs of disk space), to me it seems far 
more practical to use the database on disk, partly because I expect 
that most of the data will not actually be needed most of the time.

	I do find it interesting that you're storing huge amounts of data in 
RAM, and I wonder what some of your reasons are for doing this.

[End of reply.]

> Shibi
> 
> 
> On Fri, Mar 2, 2012 at 4:51 PM, André Warnier <aw...@ice-sa.com> wrote:
> 
> > On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw...@ice-sa.com> wrote:
> >>
> >>  Shibi Ns wrote:
> >>>
> >>>  I would like terminate current sever Child  process after the end of
> >>>> current request because some data is cached and data is changed after
> >>>> the
> >>>> process creation.  The data cached during InitChild phase
> >>>>
> >>>> Is it possible ?
> >>>>
> >>>>  It is certainly possible (*), but really, really, really inefficient.
> >>>>
> >>>  You are going to force your Apache server to create a new child process
> >>> for each HTTP request ? That sounds crazy.
> >>> You should review your application logic instead.
> >>>
> >>>
> >>> (*) The easiest way would be to set MaxRequestsPerChild to 1 in your
> >>> server configuration.
> >>> But don't think that I would recommend doing that.
> >>>
> >>>
> >>  Shibi Ns wrote:
> > > Not each request , it's based some data change in database and this could
> > > happen couple of times in day that's all. We really don't want to go
> > ahead
> > > bounce the application in order refresh the cache
> > >
> >
> > I don't now what you mean by "bounce the application", but why do you not
> > do something like this :
> >
> > At the beginning of your first "handler" :
> >
> > our $CACHED_DATA;
> >
> > unless (defined $CACHED_DATA) {
> >  $CACHED_DATA = _load_cached_data();
> > }
> >
> > ....
> >
> > within the request processing :
> >
> > our $CACHED_DATA;
> >
> > if ($condition) {
> >   $CACHED_DATA = undef;
> > }
> > return OK;
> >
> > ...
> >
> > sub _load_cached_data {
> > # load and cache whatever data needs be
> > my $cached_data;
> >
> >  ...
> >
> >  return $cached_data;
> > }
> >
> >
> >
> 
> 
> -- 
> --Shibi Ns--
> 


Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/