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

2798Forking HTTP::Daemon

Expand Messages
  • Thom Eden
    Jul 11, 2003

      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
    • Show all 4 messages in this topic