2800Re: [soaplite] Forking HTTP::Daemon
- Jul 11, 2003I'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
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:
> 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
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
/* Michael A. Nachbaur <mike@...>
"`The best way to get a drink out of a Vogon is to stick
your finger down his throat...'"
- << Previous post in topic Next post in topic >>