2801Re: [soaplite] Forking HTTP::Daemon
- Jul 11, 2003
> I am building a web service at a customer site using SOAP::Lite. GivenFor this sort of volume I wouldn't use Daemon.pm, personally I don't think
> 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
its up to handling those sorts of load levels, however...
> I notice that the handler gets bogged down while performing theThe daemon is unthreaded and and the socket is blocking, if your sleep was
> 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
longer than the connection timeout your additional clients would timeout
waiting for the first connection to finish.
> I found an example of a forking server, which spawns a specified numberIf you _really_ need to roll your own instead of going with something a
> 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.
bit more robust (and tested) like a service running under Apache the I'd
recommend threading rather than forking your handler processes...
I've attached a very quick a dirty ThreadOnAccept.pm module, but it should
really be rewitten using Thread::Pool so that a denial of service attack
isn't so easy.
> This may turn out to be an acceptable solution, though, as my atomicThats fairly poor design choice, if you're going to drop a server like
> 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?
this onto a publically accessible site where you can't control the number
of people connecting to it, you shouldn't make assumptions. The only way
an assumption like this is valid is if you are the only one going to be
running a client process to connect to this server.
> In the SOAP::Lite examples, there are a couple of "semi-published"ForkOnAccept works fine for me, but again, I'd recommend using ithreads
> 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
and Perl 5.8(.1)
> I know I can't be the first guy to come along and want to create a SOAPNo you're not, I've got plenty of stand alone SOAP services, but for a
> service without using Apache, CGI or mod_perl... If anyone has any
> pointers, I would be greatly appreciative!
production service, where I can't control whats going to be hitting the
server, or one where I'm expecting the sort of load you seem to be
expecting, I'd go for Apache, CGI or mod_perl...
Dr. A. Allan, School of Physics, University of Exeter
- << Previous post in topic Next post in topic >>