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

Re: [soaplite] Forking HTTP::Daemon

Expand Messages
  • Alasdair Allan
    ... use threads; use threads::shared; use strict; use vars qw(@ISA); # based on SOAP::Transport::HTTP::Daemon use SOAP::Transport::HTTP; @ISA =
    Message 1 of 4 , Jul 11, 2003
      > 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
    • 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 2 of 4 , Jul 11, 2003
        ---------- 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.