posted on Wednesday, June 16, 2010 12:46 PM
It’s been a good long while since I wrote an installment of Load Balancing for Developers, but you all keep reading them, and they are still my most read blog posts on a monthly basis, so since I have an increased interest in WAN Optimization, and F5 has a great set of WAN Optimization products, I thought I’d tag right onto the end with more information that will help you understand what Application Delivery Controllers 
(ADCs) are doing for (and to) your code, and how they can help you tweak your application without writing even more code.
If you’re new to the series, it can be found here: Load Balancers For Developers on F5 DevCentral This is number eight in the series, so if you haven’t already read seven, you might check out the link also.
To continue the story, your application Zap-N-Go! Has grown much faster than you had expected, and it is time to set up a redundant data center to insure that your customers are always able to access your mondo-cool application. The solution is out there for you, Application Delivery Controllers with WAN Optimization capabilities turned on.
WAN Optimization is the process of making your internet communications faster. The whole idea is to improve the performance of your application by applying optimizations to the connection, the protocol, and the application. Sometimes application is very specific – like VMWare VMotion, sometimes it is more generic, like CIFS or HTTP. There are multiple steps to get there, but it all starts in one place… Your application places information on the wire, or requests information from a remote location, and you need it to be snappy in responding.
SOMETIMES THERE ARE TWO.
There are two scenarios for using a WAN Optimization platform, symmetric and asymmetric. In the asymmetric case, the ADC is performing optimizations that can be understood by generic clients – speeding TCP connections, protocol specific enhancements that can be done on one end without confusing a typical client, etc. In the symmetric case, the ADC is connected to another remote ADC, and the two can perform more optimizations because they both “speak the same language”.
Have you ever tried to download a zip file with the wrong MIME type set for zip files on the web server you’re downloading from, or used FTP to download a text file from a Linux machine to a windows machine without setting options correctly? The client receives it as something completely different, and in the worst cases the resulting file is unusable even if you open it with a zip program. That is what happens when symmetric optimizations are turned on and there is no complimentary ADC on the other end. The ADC that is there expects things to be compressed, deduplicated, and sometimes even encrypted… But there is no device on the other end capable of doing so, and what comes across is seen as garbage. Because of this, assymetric communications are assumed by most ADCs unless you tell them differenty, so remember that.
When moving instances of an application to a remote data center, you still want centralized development, and most companies want centralized database also. It seriously complicates things if your data set is suddenly distributed amongst several databases because you keep a copy on each premise, so most organizations don’t unless the secondary premise is a replicated disaster recovery environment, in which case it won’t impact Application Development for the most part (as long as you don’t have things like hardcoded public IPs anyway – so don’t have them).
THE LONE RANGER
We’ll tackle asymmetric first because it is less wordy. Simply put, asymmetric optimizations are well-known optimizations that should not impact your application in any way. Since they vary a bit vendor to vendor, I’ll stick to the generic ones, and try to be inclusive.
Protocol Acceleration. From MAPI to HTTP, most WAN Optimization products offer you acceleration of an array of protocols that happen “under the covers”, and are tested against standard protocol implementations. These optimizations do things like reduce chattiness of the underlying protocol or keep connections alive for longer periods of time than default settings would normally allow. The speed increases are real, and in a lossy network can be large, but for most protocols this is not the most phenomenal improvement. It is one of the most time-tested though.
Rate Shaping. You have a ton of data going through that connection to the Internet, most ADCs will allow you to prioritize it so that your AppDev weekly MMO game can still go off without a hitch while serving the needs of both datacenter and end clients! Seriously though, rate shaping allows you to give priority to the protocols you find most important. If you run a commodity trading business and your traders use IM for timely communications about the market, then giving IM a high priority is likely important, but for everyone else, giving IM limited bandwidth is worth considering unless you’ve worked it into your daily business. Doing so gives more bandwidth to mission critical applications without having to write code – think of it like a priority queue where you set priorities by type of traffic.
Web Caching. Most ADCs and/or WAN Optimization vendors support Web Cache Communication Protocol (WCCP), which allows you to offload caching from your webserver (or other server) to the Web Cache appliance or server. This has a net result of caching across applications and servers, and reducing the burden on your servers. If implemented correctly, your application will see no change, but the web cache will hold repetitive bits of your output HTML to speed access. The easiest example of WCCP speeding delivery of your application code is images. Images don’t change much, so imagine if they were all cached on the WCCP device until changed, and instead of your web server digging them off of disk or storing them in memory, the cache could deal with them for you, and your server could handle more requests instead. The same is true for repetitive chunks of HTML and other frequently sent objects. This is very similar to calling a webservice to distribute the workload of your application across machines, just done at a different level, and no coding required on your part.
SYMMETRY CAN BE A BEAUTIFUL THING
Next is Symmetric optimization, which encompasses a lot more useful stuff from an AppDev perspective, and is a bit more vendor/product specific. I’ll do my best to cover it generically, but if you’re not an F5 customer (and aren’t able to become one at the moment ;-)), you should check with your vendor about how exactly they achieve similar effects.
Symmetric has the advantage mentioned above, that there are two devices that understand each other, one at each end of the connection. This gives you the following fun bits to your application for free (free as in once the ADC/WAN Opt products are in place your apps can take advantage of them without effort).
Compression. Before the data is shipped out on the wire, it is compressed. Think of it like you are sending everything winzipped or gzipped, without the server overhead of doing so. This is a large performance gain and frees space on the wire in most deployments. Of course you could craft a scenario where compression didn’t offer much reward, but in real-life use it tends to do really well at crunching data. Like everything else, algorithms applied strongly influence the quality of compression, so check with your vendor.
Enhanced TCP optimizations. When you know exactly what device will be on the other end of your TCP connections, you can apply optimizations that wouldn’t make it if the connection was to a random client. This is just the same as if you could guarantee that all of the browsers hitting your web app were going to be Firefox, there is much code you could eliminate and some tricks you can use because you know how the browser will act. The same is true with TCP connections. Knowing exactly how the other end will react, some tricks can be applied and chunks of the communication can be streamlined.
Encryption. Again, knowing that there is a decryption tool at the other end that has the correct algorithms to decrypt your stream means you can encrypt data going between the two. Doing so on your ADC means that you save the intensive processing required on servers to do the same thing. That leaves more processor and I/O time for your application to service requests, always a bonus. It also allows you to debug easier because the ADC is off-box, so you won’t be stuck with an encrypted stream that fails and trying to debug where it went wrong.
Tunnels. (NOTE: I am not at all certain that these are well implemented in every vendor, please check with yours if you are not an F5 customer…) tunnels allow point-to-point communications through the Internet. For BIG-IP purposes they’re called iSessions, and they enable some interesting extended functionality that we’ll talk about in the next blog that talks about how best to make use of symmetric architectures in the AppDev context. In the case of F5, tunnels also enable selective encryption. You can create a secure, encrypted connection between two BIG-IP boxes, while other connections are point-to-point but not encrypted. Tunneling just happens for you, no need to create the PPTP connection from code, just send data to the correct IP and you’re off.
Data Deduplication. Lots of the data sent over a connection between two data centers is boring. Just like when you write a ton of very similar code over and over because it’s not in the right place to genericise, but you would if you could, there is a lot of duplicate data flowing over your pipe. Symmetric data deduplication removes all the duplicates on the way out, and restores them at the other end. This means that your application will notice no difference, but the more repetitive your data the more gain you’ll see. There are a lot of variables that impact deduplication, but the size of the deduplication cache is key – how much data can be stored in the list of duplicates maintained while deduping the stream (remember that deduplication on a stream is like file I/O, you see it as it goes by, but really don’t have a master list of what’s coming and going, so you have to work on it as-it-flows. So if the first 20 meg of data has a ton of duplicates, the memory/disk set aside to hold the list of replacements fills up quickly. Make sure you know how your vendor handles this situation, and that they have a smart method of flushing the duplicate cache.
TA-DA!
There you have it, I’ve seen cases with some outrageous performance improvements when all of these items are utilized, and seriously large improvements when only some of them are turned on. But of course all situations are different, you understand your applications, operations knows your Internet connection size and usage, and now you know what kinds of performance enhancements you can get from WAN Optimization technologies.. Next time I revisit this series I’ll explain how you can use WAN Optimization Controllers in your application environment to get a variety of benefits including redundancy and optimization.
Related Articles and Blogs:
