Is client-side connection pooling ever NOT justified?

[Mike]

Perhaps the statement in the subject is a bit strong (never say never), but
anyway: I'm having a bit of a problem with a co-worker who created a custom
TCP socket-based client-server application (the protocol is proprietary).
This application processes aver 15 million transactions (short-lived,
average less than 1 second each) per day, concentrated over a few hours, and
with a farily high level of concurrency. It is mission-critical to our
company. Anyway, the client side of this application creates a new socket
connection to the server for *every* transaction, and closes it upon
completion. Correspondingly, the server accepts each new connection and
then discards it at the end of each transaction.

My co-worker's rationale is that creating a new connection represents just a
fraction of the total time it takes to process each transaction. He also
states that this "saves memory because the application does not have to keep
these pooled connections in memory". I completely, vehemently, disagree
with this. First, although the connection time may be small relative to the
time it takes to process a transaction, the overall effect is amplified by
the sheer number of transactions. Secondly, the amount of garbage being
created - on both the client and the server - by constantly creating new
connections has to be far worse than the memory needed to pool a hundred or
so connections. Not to mention system resources - the socket itself - that
must be reclaimed by the system.

I'm looking for any comments to either debunk my thinking, or that I can use
as ammunition to debunk my co-worker. Its really rather important, so I
would greatly appreciate any help here.

Thanks,

Mike

 

[Jon A. Cruz]

This application processes aver 15 million transactions (short-lived,
average less than 1 second each) per day, concentrated over a few hours, and
with a farily high level of concurrency. It is mission-critical to our
company.

Give that, it does sound like he's making horrible choices. Measure (or
calculate) things a bit and then run some simple tests to simulate the
process.

If, for example, a single client will make n connections per minute at
the peak time, for a certain number of minutes, you should then be able
to calculate the time to startup and shutdown each connection. IIRC,
estabilishing a TCP connection can be relatively expensive (hence one of
the reasons for persistent connections in HTTP)

My co-worker's rationale is that creating a new connection represents just a
fraction of the total time it takes to process each transaction.

But what of measurements? Metrics trumps guesses every time.

Just set up a simple test case and have a bunch of machines start
hammering your server randomly. Having several machines do this is part
of needed testing.

 

[Bruce Lewis]

My co-worker's rationale is that creating a new connection represents just a
fraction of the total time it takes to process each transaction.

There's a problem with this rationale related to how TCP/IP works. When
a new connection is opened, transmissions are sent at a pessimistic
rate, assuming it's easy to overload the network. Over time, the
connection "learns" that it can transmit faster.

Unless TCP/IP has changed drastically since the last time I knew what I
was talking about, this information is discarded when the connection is
closed. The next connection to the same remote host will have to
re-learn the most effective transmission speed.

Creating a new connection does not just add the amount of time it takes
to create that connection. It also slows down the transmission of the
transaction.

 

[Peter Schoaff]

My co-worker's rationale is that creating a new connection represents just a
fraction of the total time it takes to process each transaction.

I was working on a similar system and profiled the connection. I was surprised
and what percentage was taken up creating and releasing the connection. It was
something like 30% of the total time, and that was with pretty large packets.

Do some profiling and I think you won't have any problem convincing him.
Measuring beats guessing every time.

 

[Keeger]

I was working on a similar system and profiled the connection. I was surprised
and what percentage was taken up creating and releasing the connection. It was
something like 30% of the total time, and that was with pretty large packets.

Do some profiling and I think you won't have any problem convincing him.
Measuring beats guessing every time.

Does Java have support for pooling sockets?

 

[Adam Maass]

Does Java have support for pooling sockets?

Not natively. The obvious thing is to send multiple transactions over the
connection once it's been established, and spawning threads on the
server-side to handle each request. Or maybe just sticking each message into
a queue to be handled by a thread pool.


-- Adam Maass