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

Re: [soaplite] Forking HTTP::Daemon

Expand Messages
  • Thom Eden
    ... From: Alasdair Allan Date: Fri, 11 Jul 2003 18:14:21 +0100 (BST) ... It looks as though Perl was installed without threading support
    Message 1 of 4 , Jul 11, 2003
    • 0 Attachment
      ---------- Original Message ----------------------------------
      From: Alasdair Allan <aa@...>
      Date: Fri, 11 Jul 2003 18:14:21 +0100 (BST)

      >
      >> 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...
      >
      >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
      >> thing.
      >
      >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.
      >

      It looks as though Perl was installed without threading support here :(

      >> 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?
      >
      >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.
      >

      The 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.

      >> 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
      >
      >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...
      >

      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 :|

      >Al.
      >--
      >Dr. A. Allan, School of Physics, University of Exeter
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.