Frequently, the IT applications delivery group finds itself in a difficult situation in having been handed the responsibility for delivering an application which – unbeknownst until then – consumes an inordinate amount of resources.
This is a classic driver for the NetScaler application delivery controller optimization capabilities. We’ve all used caching, SSL offload, load balancing, compression offload, TCP multiplexing, and even redirect policies to ease the strain on and reduce the number of back end servers. Pretty much “old hat”.
Well now – as the old joke goes – the captain wants to go water skiing, but with Web 2.0 applications.
Now that the standard web application optimization is straight forward, there is a new breed of applications that can cause us delivery woes.
They are applications built on an architecture that maintains long lasting connections to the users’ browser or other applications and uses those connections to push out data asynchronously, without user intervention. The applications typically provide services such as Mash Ups, team based collaboration portals, subscriber based feeds, and more.
The point is that these applications will typically create and maintain connections from the server back to the client such that they can trigger outbound communications to all subscribed users. This is shown on a single client basis in the diagram to the left.
Furthermore, if the application is successful and enjoys a high rate of adoption, this results in the requirement for the server to maintain a huge number of connections and thus results in huge loads on the servers. Commonly, as the application or service becomes more successful – more widely subscribed to – additional servers must be implemented.
Sadly, this proliferation of servers is not driven by application processing load, but by the system hitting the connection management bottleneck.
NetScaler to the Rescue
The best way to address this problem is through the proven NetScaler connection multiplexing technology that optimizes connections to conventional back-end web servers.
Since the communications are initiated by the application and information is pushed to the client, however, the standard NetScaler VIP/Service/Server configurations cannot be used. This is due to the fact that the Web 2.0 application must keep track of a variable number of subscribed clients, and must send the data to them asynchronously.
As such, TCP connections must be set up and maintained to communicate with those individual users.
Implementation of the NetScaler “Push-VIP” can address this problem, however.
As stated above, the primary application bottleneck is not keeping track of the subscribed users, but rather the connection management. Therefore, letting the NetScaler manage and maintain the connections exploits the connection multiplexing services that the NetScaler performs well.
The following is a brief summary of how it works.
Step #1: Two VIPs are configured within the NetScaler Configuration – a standard Load Balancing-VIP (LB-VIP) and a Push-VIP. While the conventional LB-VIP s client facing, the Push-VIP is server facing. In the complete configuration, the LB-VIP, and its Services and Servers, are bound to the Push-VIP.
Step #2: The user hits the externally facing LB-VIP, and subscribes to the site via a normal NetScaler-serviced website connection. Because the request is associated with the Push-VIP, the NetScaler inserts special headers that cause the back-end application to catalogue the user request, and assign a unique tag (“label”) for each user.
Step #3: The Web 2.0 application inserts this user-specific value as part of the label. Then, for each registered user, the application pushes additional information to the single NetScaler Push-VIP. This results in the application reusing the existing TCP connection to that single NetScaler Push-VIP for all user communications, incurring minimal connection management overhead.
Step #4: The NetScaler then fans out the communications to the connected users, thus offloading connection management from the back end servers.
In the above sequence, Step #2 will require minor modifications to the back-end application code. Examples of such code are provided by Citrix for ease of implementation.
So What Are These Applications?
These applications appear as those offering collaboration or subscription services. Applications that provide team collaboration services – such as calendars, blogs, or content sharing often use the Web 2.0 technologies. Also, if the application turnover sheet states that the new application is COMET or Bayeux based, ask if it provides asynchronous data push to the client.
If there’s a hit, think of the NetScaler Push-VIP.
For a more detailed explanation, including an examination of the inserted headers, please refer to Vamsi Korrapati’s BLOG.
As usual I welcome your comments.
Post a comment or send an email
Also, follow me on Twitter