jimc has asked for the wisdom of the Perl Monks concerning the following question:

Ive got a SOAP server running, and Im trying to assess the performance impacts of making the Listen queue really big, and letting requests pile up there.

The client is a java program that I expect to be quite bursty in its traffic profile - long stretches of boredom (no requests), punctuated by sheer panic (a flood of them). The client may use many threads to send the reqs.

Id prefer that they wait synchronously on the replies; acks and delayed callbacks seem like protocol complexity and overkill, but this is subject to system-wide performance estimates.

Im thinking that this will be the light-weight approach. 

$daemon = SOAP::Transport::HTTP::Daemon
	-> new ( LocalAddr => $gwcf->{soap_host},
		 LocalPort => $gwcf->{soap_port},
		 Listen    => $gwcf->{soap_listen_queue} || 5,
		 ReuseAddr => 1 )
	-> dispatch_to ('GwApi', 'TryMe');
FWIW (and this is pretty cool), the code after this forks a bunch of times, (after the Listener socket is bound), and each slave-server process accepts requests as available. So this is really a IO::Socket::INET question, despite the SOAP::Lite layer Im using (thx & kudos to Pavel Kulchenko, Kieth Brown, DevelopMentor)

The work-load is basically self-balancing, and appears to be as light as it can get :-) This is the case on LINUX AND ON SUNOS 5.8.

The only downside is that its hard to tell what the work-load is, and whether (for instance) new slave-servers should be spawned to help out.

Im aware of NET::Server::PreFork, but it doesnt appear to do anything more fancy than restart slaves that have exited. I dont want to use timestamps in the SOAP requests, that would expose the server to stupid time-of-day tricks.

So I seek sufficient Network/Sockets Fu to be able to win the perl vs java arguments that may be in my future. tia

  • Comment on how to find out whats in a LISTEN queue

Replies are listed 'Best First'.
Re: how to find out whats in a LISTEN queue
by traveler (Parson) on Jan 02, 2003 at 23:32 UTC
    Before you start testing this you might want to ensure that your kernel supports "large" values for the listen queue. In general, on *nix systems, that limit is set by the kernel in a constant called SOMAXCONN. On (at least some versions of) SUNOS the kernel variable SOMAXCONN is set to 5 and the kernel must be patched/recompiled/relinked to change the value. In the 2.4.19 linux kernel it is defined as 128 -- pretty large.

    Also note that you can check to see how much queue is being used by doing netstat -n|grep SYN_RCVD this will show waiting connections. Be sure to only count the ones on the socket in which you are interested, though. (That is, netstat -n|grep SYN_RCVD|wc -l is not enough.) Some linux netstats may not report that value and/or may not document it in the documentation. "Use the source, Luke."

    HTH, --traveler

[reply]
[d/l]
[select]
      For systems that arn't running a Dark Ages version of SunOS (Read Solaris) you can set the queue length on a live system with the command:
      /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max <NUM>Solaris 2 -> 2.4 max is really 32, 2.5, 2.5.1 2.6 etc its 1024 and 7 8 9(SunOS 5.7, 5.8 and 5.9) it is 2048.

      If you are Running a version of SunOS you still need to recompile the Kernel (Read SunOS 4.1.3u or earlier) to make these changes you should think about just hiring some monkey to shout ones and zeros at the ethernet port.

      -Waswas
[reply]
[d/l]
        cool - I do have ndd, on SunOS 5.8 tcp_conn_req_max_q and q0 are 128 and 1024 respectively. It seems that this simple approach still has a chance.

        btw - it seems I havent yet mastered reply replys yet. soon..

[reply]
      yes ! or rather crap !

      I forgot to add that Id looked at netstat -tnee output, but couldnt see anything on Rcv-Q, now I know more.

      looks like I need to do a more complicated application-level handling of the requests, with a callback on completion.

      thx for heading off a fruitless investigation.

[reply]

Back to Seekers of Perl Wisdom