Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 3 Really good reasons you should use TCP multiplexing
posted on Tuesday, October 14, 2008 5:10 AM

AJAX. SOA. Social network API integration.

What is TCP Multiplexing? All of aforementioned technologies have one thing in common. Okay, they have more than that in common,  but for the purposes of this discussion there's one very
TCP multiplexing is a technique used primarily by load balancers and application delivery controllers (but also by some stand-alone web application acceleration solutions) that enables the device to "reuse" existing TCP connections. This is similar to the way in which persistent HTTP 1.1 connections work in that a single HTTP connection can be used to retrieve multiple objects, thus reducing the impact of TCP overhead on application performance.

TCP multiplexing allows the same thing to happen for TCP-based applications (usually HTTP / web) except that instead of the reuse being limited to only 1 client, the connections can be reused over many clients, resulting in much greater efficiency of web servers and faster performing applications.
relevant property they all share: they tend to be very TCP connection heavy  implementations.  

AJAX lends itself to keeping open multiple TCP connections between the browser and the server; using up connections that reduce the overall capacity of your server. SOA decomposes applications and business logic into services, and then encourages the reuse of those services across multiple applications, resulting in a trade-off between duplicated code and multiple TCP connections. And the use of APIs to integrate social networks, especially those driven by real-time updates like micro-blogging site Twitter, increase the number of TCP connections on a server dramatically.

TCP Multiplexing reuses existing connections The increase in TCP connections can overwhelm a server in a kind of unintentional DDoS (Distributed Denial of Service) attack. It certainly wasn't the expected or intended behavior, but a site or service can easily twitter under high loads, causing outages and outrage simultaneously.

Thus, there are three really good reasons to employ TCP multiplexing in your architecture.

1. IMPROVES PERFORMANCE
All applications can benefit from the improvement in performance seen when a server does not need to open and close hundreds or thousands or more of TCP connections a second. By removing the need to manage the TCP connections constantly, and instead reuse them across large numbers of requests, applications focus solely on generating and serving content, which improves application performance overall.

2. IMPROVES CAPACITY OF SERVERS
Generally speaking, servers are capable of handling only X number of concurrent

users and that number, in the past, has almost always been closely tied to the number of simultaneously open TCP connections the OS and application or web server can manage. By reducing the number of TCP connections required to serve the same number of users and requests, it leaves the server with the ability to open more connections and thus serve more users and requests.

3. MAKES CONSOLIDATION EASIER

Because the use of TCP multiplexing can improve the capacity of servers, it makes it possible to reduce the total number of servers you need to serve the same user base. The fewer servers you need means you can redistribute them for other uses or just shut them down, which lowers operating and management expenses. Or you can delay the need to acquire additional servers if you're still growing, putting off the investment for a future date.

TCP multiplexing was one of the coolest (in my opinion) technologies to enter the application delivery space. It's a fairly old feature at this point, but it's still one of the most beneficial, useful technologies available in load balancing and application delivery controllers today.

If you aren't using it, you should be. 

Related Links
Persistent and Persistence, What's the Difference?
SOA and Web 2.0: The Connection Management Challenge
The Impact of the Network on AJAX
The Impact of AJAX on the Network [white paper] (text version)

Follow me on Twitter View Lori's profile on SlideShare AddThis Feed Button Bookmark and Share



Email This
  del.icio.us
      

Feedback


10/14/2008 5:57 AM
Gravatar Hello,

I understand the concepts from your example but I am not sure on how to actually implement something like this.

Do you have to buy a load balancer such as the http://www.f5.com/products/big-ip/ ?


Brett ODonnell
Brett ODonnell

10/14/2008 6:07 AM
Gravatar @Brett,

The feature is something that is standard with load balancers like BIG-IP, so that would be one way (and certainly the easiest from an implementation/deployment perspective) to make use of TCP multiplexing.

However, if you have control over the client, you should be able to implement similar functionality that provides almost the same benefit. You can't share the connection with other clients like you can if you put a load-balancer into the mix, but you can reduce the number of connections used and reuse a single connection, which can help you manage scalability by ensuring you can map clients == connections.

You should be able to use a design pattern like a singleton to open a single connection and keep it from closing by reusing it instead of opening up a new connection every time you need to make a request.

You may have to drop a tiny image on the server (like a 1x1 GIF) and request it periodically to ensure the TCP connection doesn't close if the user is idling too long. You could also increase the web server's time out to help with this but that might not be optimal if you have a mix of client types and applications/sites on the same server.

This should reduce the number of connections and make it possible to better predict the capacity of the server and when you might need a second or third.

HTH,
Lori

Lori MacVittie

10/14/2008 8:29 AM
Gravatar I have managed sites and systems that sit behind various flavors of TCP Multiplexing devices and have learned from real world results why this rocks.
- Nearly all Operating Sysytems need to track every Network connection in memory that is not paged to disk.
- This non-paged memory pool is fairly small so filling it with network connections will hamper the OS in doing other critical tasks.

Lori does a great Job of De-Geeking the root of why this is so important to improving performance, and I too was a skeptic until I first saw it drop my CPUs by nearly 25% several years ago on a first gen device from a different vendor. Later when my company purchased some LTMs we saw a similar gain in performance yet again, helping that company make it through the fourth quarter a little easier. Of note is the fact that the baseline of users and complexity of our codebase had also grown geometricly in between these two architecture changes.

Hope this helps,

Carl B
Carl B

10/16/2008 6:40 AM
Gravatar Nice article, maybe you should also include the how to do this on the F5 section so the article become useful instead of learning a concept that I have no clue how to implement.
Name

10/19/2008 4:33 PM
Gravatar Could you please explain (or preferably point to a white paper or other reference that explains) what "TCP multiplexing" is?

It sounds like you're talking about TCP connection termination, but it's hard to tell what's really going on here.
Mark Nottingham

10/20/2008 3:41 AM
Gravatar @Mark

I've done some searching to see if we have a white paper on the subject and though we mention it a lot - it is a core feature of BIG-IP - we don't have anything that just explains what it is. We may have in the past, when it was new, but that was years ago. Sometimes we suffer from the curse of knowledge and assume that technology that is years old to us is well-known, and that's just not always true. I shall see about remedying the situation. In the meantime, I will try to explain more thoroughly.

Termination is part of the equation, yes. The ADC sits in between and terminates the TCP connections from the client. It then opens X number of connections to the servers and keeps them open for a specified number of requests/time and uses them to fulfill requests. It will reuse them for requests across clients and requests. So ten clients may be making requests and using the same two server-side TCP connections. The more clients and requests involved, the more efficient the reuse of server-side connections becomes.

While the number of server-side connections open grows as the number of clients and requests increases, it does not increase linearly. The relationship between client-side and server-side connections is many to many, but it is not 1:1; it's more along the lines of X:1, where X is determined by the ADC based on response time and configuration.

The diagram in the post above depicts TCP multiplexing on a simple level. There are 5 client connections to the ADC, but only 1 connection from the ADC to the server. All requests from those 5 client connections are fulfilled over that 1 server-side connection. In a scenario in which TCP multiplexing is not used, there would be a minimum of 5 server-side connections; 1 for each client-side connection.

TCP multiplexing is very similar to database connection pooling, in which applications reuse a pool of database connections managed by the application container (such as a Java EE application server). It's not quite the same, as only one application can use a database connection at a time and with TCP multiplexing the same connection to a server might be "used" by multiple clients nearly simultaneously because only the ADC sees the server-side connections. The client is completely divorced from server-side connection management, it sees the ADC or other proxy as its server/end-point.

I hope that's a better explanation. If not, please feel free to ask specifics or e-mail directly. I'll be happy to try to elucidate further and will also see about getting a white paper together that further digs into the topic.

Thanks much!
Lori MacVittie

11/1/2008 2:00 AM
Gravatar Thanks, that's very helpful. It seems that by its nature, this works at layer 7, no? I.e., it has to have knowledge of application semantics to reuse connections.

Mark Nottingham
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 2 and type the answer here: