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

2800Re: [soaplite] Forking HTTP::Daemon

Expand Messages
  • Michael A Nachbaur
    Jul 11, 2003
    • 0 Attachment
      I'm a relative newbie at SOAP as well, but I have (I think) successfully
      created a soap daemon that does just this. My requirement was that it should
      be able to be hammered with tons of requests in a short span of time, but to
      be dormant for pretty much of the time. Another requirement was security,
      and while I wanted to use secure certificates and SSL, SOAP::Lite died every
      time I tried it.

      My hack solution was to use TCP Wrappers to limit whom I would talk to.
      Attached is my SOAP transport, and a trimmed-down soapd executable that uses
      the transport.

      If anyone has a better way of doing this, I would much appreciate it!

      On Friday 11 July 2003 06:34 am, Thom Eden wrote:
      > Folks,
      > Pardon my ignorance, I'm a newbie at this...
      > I am building a web service at a customer site using SOAP::Lite. Given that
      > volumes will initally be in the 100,000/day, growing to twice that in a
      > year, we want to ensure the service has the oomph necessary to handle the
      > volume. When writing a simple server which uses
      > SOAP::Transport::HTTP::Daemon, I notice that the handler gets bogged down
      > while performing the dispatch_to work. I took the example Echo.pm and put
      > in a 10 second sleep, and noticed that I routinely get just over 10 second
      > response times, as expected. However, when I initiate 2 or more clients,
      > response time becomes n (number of clients) * 10.?. This is clearly not a
      > good thing.
      > I found an example of a forking server, which spawns a specified number of
      > children. I adapted it to my use, and notice that performance degradation
      > is only slightly worse when the number of children forks is greater than
      > the number of clients, which is a good thing. However, when the number of
      > clients expands beyond the number of child forks, performance again
      > degrades beyond what is acceptable. This may turn out to be an acceptable
      > solution, though, as my atomic transactions may only turn out to be about 3
      > seconds long; after all, how many real requests will come in over a 3
      > second span?
      > However, the architect in me would like a solution where the server takes
      > each request and forks a process to handle it, thus allowing the handler to
      > return to its work; handling requests.
      > In the SOAP::Lite examples, there are a couple of "semi-published" modules,
      > namely SOAP::Transport::HTTP::Daemon::ForkAfterProcessing and
      > SOAP::Transport::HTTP::Daemon::ForkOnAccept. I cannot get the latter to
      > work, even with the sample server code, it returns "500 unexpected EOF
      > before status line seen" and the server punches out
      > getsockname() on closed socket Symbol::GEN0 at
      > /opt/perl5.6/lib/5.6.0/sun4-solaris/IO/Socket.pm line 186. Use of
      > uninitialized value in string eq at
      > /opt/perl5.6/lib/site_perl/5.6.0/HTTP/Daemon.pm line 124. Use of
      > uninitialized value in gethostbyaddr at
      > /opt/perl5.6/lib/site_perl/5.6.0/HTTP/Daemon.pm line 129. Use of
      > uninitialized value in subroutine entry at
      > /opt/perl5.6/lib/site_perl/5.6.0/HTTP/Daemon.pm line 129. Bad arg length
      > for Socket::inet_ntoa, length is 0, should be 4 at
      > /opt/perl5.6/lib/site_perl/5.6.0/HTTP/Daemon.pm line 129.
      > Hmmm. Not sure what is going on here. Any clues would be great.
      > The former (ForkAfterProcessing) works as advertised; however, I notice the
      > process stack on my Solaris server keeps getting new processes (for each
      > fork) which never expire. After a few minutes of load testing, my machine
      > is about dead. I stop testing and wait up to an hour, yet none of the
      > forked processes dies. This is clearly a bad situation!
      > I know I can't be the first guy to come along and want to create a SOAP
      > service without using Apache, CGI or mod_perl... If anyone has any
      > pointers, I would be greatly appreciative!
      > Thom Eden
      > the@...
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

      /* Michael A. Nachbaur <mike@...>
      * http://nachbaur.com/pgpkey.asc

      "`The best way to get a drink out of a Vogon is to stick
      your finger down his throat...'"
    • Show all 4 messages in this topic