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

2801Re: [soaplite] Forking HTTP::Daemon

Expand Messages
  • Alasdair Allan
    Jul 11, 2003
    • 0 Attachment
      > 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.

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

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

      Al.
      --
      Dr. A. Allan, School of Physics, University of Exeter
    • Show all 4 messages in this topic