Loading ...
Sorry, an error occurred while loading the content.

478Re: [soaplite] Re: Fwd: Process-Pool Forking SOAP Server.

Expand Messages
  • Paul Kulchenko
    Jun 16, 2001
    • 0 Attachment
      Hi, Michael!

      > I believe that at least one moderate performance server should be
      > included in
      > the main distribution. Also, I think that it should be installed by
      > default,
      > without having to copy by hand from examples/ directory. I would
      Absolutely. I agree with you. I would like to include simple daemon,
      bulletproof daemon and nonblocking daemon.

      Your solution might work as bulletproof choice, however some
      modifications are still required. First of all, Daemon.pm shouldn't
      be Daemon, it might be SOAP::Transport::Daemon (because it'll provide
      methods suitable for HTTP, TCP and other daemons). I would also like
      to add:
      1. changing user and group ids
      2. tainting
      3. chroot
      4. relaunch on signal

      Everything is optional, so you can choose whatever you need.

      I would like to make it less Unix-oriented if possible (esp. for
      non-blocking server, since it can run on almost any platform) and
      drop 'our', so it'll work on 5.005 also. Everything else looks fine
      for me :). I'll try to come up with TCP non-blocking server next week
      and accomodate those changes for HTTP-based server also.

      Best wishes, Paul.

      --- Michael E Brown <michaelbrown@...> wrote:
      > Paul,
      >
      > I believe that at least one moderate performance server should be
      > included in
      > the main distribution. Also, I think that it should be installed by
      > default,
      > without having to copy by hand from examples/ directory. I would
      > not have
      > bothered writing my own if I had known there were already others in
      >
      > existence. I tried both of the published modules and I coudn't get
      > either one
      > up to an acceptable level of performance.
      >
      > From my testing, the server modules included by default are not
      > acceptable
      > for real load at all, so I was desperate enough to make a go at
      > writing my
      > own module. The thing that I especially like about my module are
      > the support
      > utilities in Daemon.pm that make it easy to track your server
      > status. Also, a
      > nice feature of my Forking module is that you can dynamically add
      > or remove
      > processes. In fact, I do that with another daemon that I have that
      > monitors
      > the active connections and spawns another soap process whenever the
      > number of
      > clients gets too high.
      >
      > --
      > Michael Brown
      >
      > On Friday 15 June 2001 10:36, Paul Kulchenko wrote:
      > > Hi, All!
      > >
      > > Here is the Forking server from Michael Brown.
      > >
      > > Now in my collection (unpublished means not included with
      > SOAP::Lite
      > > yet):
      > >
      > > ForkAfterProcessing (published) from Peter Fraenkel
      > > ForkOnAccept (published) from Michael Douglass
      > > preforking daemon (unpublished) from Roger Foskett
      > > Forking and Preforking daemon (unpublished) from Douglas Bonar
      > > Forking server (unpublished) from Michael Brown
      > > My own work with NetGeneric::Server (not ready)
      > >
      > > Now, the question is how to include all these modules into the
      > > distribution? Easiest way is to include them all and let users
      > > decide, but it might be not the best option, just because it may
      > lead
      > > to confusion and if we can't decide why users should :)).
      > >
      > > Anyway, what is all's opinion? Should I carefully review them and
      > > decide? Should someone more experienced with TCP processing do
      > it?
      > > Include them all?
      > >
      > > Ideally I would like to have as many as needed (but not more)
      > modules
      > > that cover your requirements (forking, select, prefork,
      > non-blocking,
      > > etc.) and at the same time maintain consistent interface among
      > > different transport on server side (at least between HTTP and
      > TCP).
      > > Thank you everybody for your help and support.
      > >
      > > Best wishes, Paul.
      > >
      > > --- Michael E Brown <michaelbrown@...> wrote:
      > > > I've had this mail bounced from the list because I'm not
      > > > subscribed. I was
      > > > wondering if you could forward it to the list...
      > > >
      > > > ---------- Forwarded Message ----------
      > > > Subject: Process-Pool Forking SOAP Server.
      > > > Date: Thu, 14 Jun 2001 23:59:53 -0500
      > > > From: Michael E Brown <michaelbrown@...>
      > > > To: soaplite@yahoogroups.com
      > > > Cc: christopher_stanton@..., michael_e_brown@...
      > > >
      > > >
      > > > Attached are some small improvements in useability and
      > scalability
      > > > of the
      > > > example soap.pl module. Please take a look and consider them
      > for
      > > > inclusion in
      > > > the base SOAP::Lite package.
      > > >
      > > > I hope that the code is clean enough to be self-documenting :-)
      > > >
      > > > There is a small improvement upon the ForkAfterProcessing.pm
      > HTTP
      > > > server
      > > > module. I've gotten improvements of 2min processing time -->
      > 5sec
      > > > processing time, and scaling from 5 clients to 50 clients
      > hitting
      > > > the
      > > > server much more heavily.
      > > >
      > > > Features in the ForkingSOAP module... this is modeled after the
      > > > Apache config
      > > > names.
      > > >
      > > > 1) MaxChildren... initial size of process pool to create
      > > > 2) MaxRequestsPerChild... children die after processing n
      > requests
      > > > (helps
      > > > with memory leaks :-)
      > > >
      > > > 3) Dynamic, on the fly adjustment of number of processes. Just
      > send
      > > > SIGUSR1 to add a process, and SIGUSR2 to remove a process.
      > > >
      > > > 4) Reporting of # of currently active children in a separate
      > file.
      > > >
      > > > 5) 'Parent' thread keeps track of children and spawns more as
      > > > needed.
      > > >
      > > > --
      > > > Michael Brown
      > > >
      > > > -------------------------------------------------------
      > > >
      > > > > package SOAP::Transport::HTTP::Daemon::ForkingSOAP;
      > > >
      > > > #use strict;
      > > > use vars qw(@ISA);
      > > > use SOAP::Transport::HTTP;
      > > > use POSIX ":sys_wait_h";
      > > >
      > > > # Implementation and Idea by Michael Brown and Christopher
      > Stanton
      > > > # Inspired by Peter Fraenkel (Peter.Fraenkel@...) and
      > > > # his ForkAfterProcessing module.
      > > >
      > > > @ISA = qw(SOAP::Transport::HTTP::Daemon);
      > > >
      > > > #Package Globals (PUBLIC)
      > > > our $MaxChildren = 16;
      > > > our $MaxRequestsPerChild = 50;
      > > > our $DEBUG = 0;
      > > > our $ChildCountFile;
      > > >
      > > > #Package Globals (PRIVATE)
      > > > our %children;
      > > > my $die;
      > > >
      > > > #Functions...
      > > > sub handle {
      > > > my $self = shift->new;
      > > > my $parentpid = $$;
      > > > my $oldchildcount = $MaxChildren;
      > > >
      > > > $SIG{TERM} = sub { foreach (keys %children){ kill(15, $_) };
      > > > $die++ };
      > > > $SIG{USR1} = sub { $MaxChildren++; };
      > > > $SIG{USR2} = sub { $MaxChildren--; };
      > > > $SIG{CHLD} = 'DEFAULT';
      > > >
      > > > while( ! $die ) {
      > > > if( $ChildCountFile && ($oldchildcount != $MaxChildren)){
      > > > print "Output new MaxChildren to $ChildCountFile\n" if
      > $DEBUG;
      > > > open CHILDCOUNT, "> $ChildCountFile" or next;
      > > > print CHILDCOUNT $MaxChildren;
      > > > close CHILDCOUNT;
      > > > }
      > > >
      > > > while( scalar(keys %children) < $MaxChildren ) {
      > > > my $childpid;
      > > > if( $childpid = fork ) { # parent
      > > > $children{ $childpid } = 1;
      > > > print " child created: $childpid\n" if $DEBUG;
      > > > } else { #child
      > > > $SIG{TERM} = sub {exit};
      > > > my $counter = 1;
      > > > while (my $c = $self->accept) {
      > > > while (my $r = $c->get_request) {
      > > > $self->request($r);
      > > > $self->SOAP::Transport::HTTP::Server::handle;
      > > > $c->send_response($self->response)
      > > > }
      > > > $c->close;
      > > > undef $c;
      > > > print " Child handled request #" . $counter. "\n" if
      > $DEBUG;
      > > > exit if ++$counter > $MaxRequestsPerChild;
      > > > exit if ! kill(0, $parentpid);
      > > > }
      > > > exit;
      > > > }
      > > > }
      > > >
      > > > $kid = waitpid(-1,&WNOHANG);
      > > > delete $children{$kid} if ($kid > 0);
      >
      === message truncated ===


      __________________________________________________
      Do You Yahoo!?
      Spot the hottest trends in music, movies, and more.
      http://buzz.yahoo.com/
    • Show all 12 messages in this topic