Re: [soaplite] Forking HTTP::Daemon
- ---------- Original Message ----------------------------------
From: Alasdair Allan <aa@...>
Date: Fri, 11 Jul 2003 18:14:21 +0100 (BST)
>It looks as though Perl was installed without threading support here :(
>> 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
>For this sort of volume I wouldn't use Daemon.pm, personally I don't think
>its up to handling those sorts of load levels, however...
>> 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
>The daemon is unthreaded and and the socket is blocking, if your sleep was
>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 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.
>If you _really_ need to roll your own instead of going with something a
>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 atomicThe system is internal, and will not be advertised outside of the firewall. Your point in general is well taken, however. What I am seeing with the current implementation in an Open Server environment (don't ask, you don't want to know) is up to 5 simultaneous clients at a time, with transactions in the 2-3 second realm.
>> 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?
>Thats fairly poor design choice, if you're going to drop a server like
>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"Thanks, but I've already received direction concerning Apache etc. here. Perhaps I'll get a reasonably acceptable solution using forks and hide several servers on different boxes behind a load balancer :|
>> 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
>ForkOnAccept works fine for me, but again, I'd recommend using ithreads
>and Perl 5.8(.1)
>> 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!
>No you're not, I've got plenty of stand alone SOAP services, but for a
>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