On just about any platform, while convenient, spawning a new process
or even a new thread to handle a new connection is not the performance
path.  Dealing with multiple requests pipelined on a single
connection, or multiple connections in a single process is more
efficient.

Do be certain that if you use the same connection over and over, you
present your individual requests and your responses to the transport
in a single "send" call.  Otherwise, you may run into issues with the
interaction of the Nagle algorithm and the delayed ACK heuristic.  The
proper fix is to present logically associated data to the transport in
one call.

Another consideration that pushes things in favor of persistent
connections.  TCP connections are "named" by the four-tuple of
local/remote IP address and local/remote port number.  If one tries to
establish and tear-down "too many" TCP connections in a given time
interval, it is possible that an attempt will be made to reuse a
four-tuple that is still in TIME_WAIT.

Specifically, if one tries to churn through more than:

             size of client local port space
             -------------------------------
                 length of TIME_WAIT

connections per second, you will get attemtps at reuse, which will
cause fun hiccups and pauses.  The proper fix is to go with persistent
connections.  The next-most-proper fix is to increase the size of the
client local port space - perhaps through making explicit calls to
bind() with port numbers in the range of 5000 to 65535.  It is _not_ a
proper fix to use an abortive close on the TCP connection or to make
the length of TIME_WAIT less than 60 seconds.

It has been way too long for me to remember what the length of
TIME_WAIT is on MPE, and I've no idea what size of port space you have
on the system running Oracle.  Common values for length of TIME_WAIT
are 60 and 240 seconds.  Common sizes for the client port space are
3975, and 16384.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *