Telephone: (215) 716-7373

Home » Application & NetAnalysis » Excessive TCP Connections

Excessive TCP Connections

Bookmark and Share

Cutting Through Opinions
Diagnosing Facts
Providing Resolution

In some applications that have been converted to TCP from older protocols such as SNA, you may encounter behavior that is unfriendly to Enterprise TCP Networks.  These applications can be fully functional and able to perform all of the tasks expected of them.  Nevertheless, they were not created for TCP and have designs that work against the efficiencies built into TCP networks.

As in many cases, the primary complaint you will hear from customers is slow performance across the WAN or hanging connections.  This is so common that it is not enough to place this particular issue very high on your Index of Suspicion.  However, if you know the application was not originally created for TCP, this issue should become more important in your troubleshooting process.

Here is how it works:

  • Ordinarily, a TCP will be created for a specific task or group of tasks.  Overhead can be very low in a well-written application--developed from conception with the abilities of modern TCP networks in mind.  One TCP can handle a great deal of data very efficiently. 
  • However, we have seen applications written for networks that were based on older protocol platforms that have been adapted for TCP networks--that open a new TCP far more often then is advisable.  In some cases, they will open a new TCP every single time a user hits the Enter Key.  Instead of a single TCP handling tens of megabytes of data, you have thousands of TCPs, each handling kilobytes of data.  In such a case, overhead can be well over 50 percent. (Unfortunately, even newer applications are inappropriately tuned--but not as poorly as this.)

Below is a sanitized example of a spreadsheet created to explain this very problem to one of our clients.


  • In a LAN, where network transport time is measured in microseconds (millionths of a second), the impact of such a design can go unnoticed.  It is still inefficient, but at 100 Mbs or higher, the delays are too short to be noticed.  In a WAN, were network transport speeds are measured in milliseconds (thousandths of a second), the delays are painful and can cause hanging connections. 
  • A properly designed Network & Application Performance Test Plan utilizing such tools as Sniffer / Ethereal / WireShark -- that is designed, executed and analyzed by a trained specialist in this particular form of analysis, will be able to diagnose and document such issues beyond a shadow of a doubt.
  •  The ability of your network to tolerate this particular issue will depend on your overall network architecture. 

For more information on this topic, click here. Or, call us at 215-822-3244.

Related Topics:

Back to main topic: Application & NetAnalysis
The Application's Interpath
Network & Application Performance Analysis Fundamentals
Building a Simple Open-Source Distributed Packet-Sniffer
Performance Tuning Is A Process -- Not A Tool
Why Network Assessments Must Include Application Behavior
The 7 Most Common Mistakes Using Packet-Sniffers
Packet-Sniffer Filtering Concepts-01
Interpath Application Flow Diagrams-01
Baselining--Stress Testing--Performance Testing--Oh My--Part ONE
Baselining--Stress Testing--Performance Testing--Oh My--Part TWO
The Saturation Point
Multi-Tier Latency Concepts-01
Application Profiling Concepts - Part One

Subscribe to receive the latest news & specials on our products:

Quick Find
Use keywords to find the product you are looking for.
Advanced Search

New Articles
All Topics
 Application & NetAnalysis
 Case Studies .
 NetAnalysis Myth Series
 Team Building
Articles RSS Feed
Shipping & Returns
Privacy Notice
Conditions of Use
Contact Us
Catalog Feed

Copyright © 1999-2013 Barry Koplowitz