#Citrix #Citrix Netscaler #HTTP Compression #Load Balance
Citrix NetScaler Application Delivery Controller (ADC) is a full featured layer 7 network appliance. One such feature is HTTP compression. HTTP compression is often a complement to Cache Redirection, Content Switching, Load Balancing and SSL Offloading features included with the Citrix Enterprise and Platinum platform license but requires enabling and a valid use-case.
This article provides instruction and visual aids to enable HTTP compression and demonstrates a valid use case scenario.
Having a license for the feature and using the feature is the topic of discussion. Enabling the feature is the prerequisite. Once enabled there are global bound policies that can have an immediate impact. Never enable HTTP Compression feature during business hours on production equipment.
Compression policies are bound locally, by service, by VIP or combination, and content specific such has HTML, text, JS, or CSS files. You can choose to compress all Java files globally or to use a content switch and redirect to Netscaler hosted virtual servers. Using one content switch, you could create hundreds of virtual servers corresponding to thousands of internal backend servers.
The point is that every web application having custom requirements is met with a single content switch virtual server and custom compression policies based on that content. Utilizing custom policies, rewrite actions, and other advanced concepts you can remove the burden of compression workloads from client or server.
The Compression feature utilizes the Gzip compression protocol
that reduces bandwidth requirements, lowering the amount of data traversing the HTTP connection between server and client.
Enabling HTTP compression might have an immediate impact to CPU performance where virtual servers exist and compression is enabled on the virtual server. Have a test NetScaler appliance of similar configuration, and take an inventory of all virtual servers.
A customer of mine upgraded their platform license from Standard to Platinum on a Sunday during IPL followed by a reboot, with the HTTP Compression feature enabled post reboot. He was unaware that HTTP Compression was enabled on several virtual servers, so the impact was negligible for testers Sunday, but come Monday morning, there was a significant impact due to the global bindings and subsequent virtual servers having compression enabled.
HTTP Compression is available under “Configure Basic Features.” I recommend doing so on a test NetScaler first to gauge the impact on the CPU. Typical user testing during the IPL window is not a perfect measure but using basic math one can calculate with a certain degree of accuracy an approximate impact to production. Never implement HTTP Compression (or any feature for that matter) on a production NetScaler's first use.
Knowing the number of HTTP requests per virtual server is imperative. I have configured a single content switch (one IP Address) with a “wildcard certificate” for over 300 virtual servers and 1400 URLs. A pair of NetScaler MPX 9700s configured as active/passive HA is capable of processing over 700,000 HTTP requests per second.
Newer versions of the NetScaler appliance can process upwards of 5 million HTTP requests per second. Amazon Web Services and Rackspace use NetScaler.
In a perfect world, the NetScaler test appliance mimics production hardware. If using the virtual appliance, the underlying hardware and hypervisor should resemble, if not share, the same physical host. Hosting a test instance on low-grade hardware provides no value regarding the performance under production loads.
Start by enabling HTTP Compression, Content Switch, Integrated Caching, Load Balancing, and Rewrite. This can be done from the web GUI or command line. Using GUI option, click Login > System > Settings > Configure Basic Features.
The default compression policies are Classic and Advanced. The global default binding is “Classic.”
Examine the built-in HTTP compression policies with firmware version 184.108.40.206. Log in to the Management GUI > Optimization > HTTP Compression > Policies > Compression Policies.
Review the built-in policies and note the two naming conventions of “ns_cmp*” and “ns_adv_cmp*.” Note the “Response Action” column.
Review the HTTP Compression settings using either the GUI or the command line interface (CLI). Modify the default HTTP Compression Parameters (settings). Log in to the Management GUI > Optimization > HTTP Compression > Configure compression settings.
Note that the default compression level is “Optimal” the bypass compression on the CPU is 100%, and the Policy Type is “Classic.” The bypass compression is of particular interest.
I prefer the command line over GUI. Open an SSH session, log in and type show cmp parameter
There are a few settings to modify based on how compression works. I prefer the Compression Level to “Optimal” which corresponds to a GZIP level of 5-7. GZIP reduces the size of the named files using Lempel-Ziv coding (LZ77). The gzip file format is specified in P. Deutsch, gzip file format specification version 4.3, Internet RFC 1952 (May 1996).
All the settings for HTTP compression are accessed by a CLI using a SSH client. Establish SSH session and type set cmp parameter
to reveal the additional arguments. The ten GZIP levels correspond to three GZIP levels on the NetScaler (Optimal, BestSpeed, and Best Compression). Optimal is a sliding compression, 5 to 7; best speed is 1 and best compression is 9.
to Optimal and -policyType
Compression is CPU-intense, but is generally less likely to be a problem if you use a physical MPX appliance than with a VPX appliance. The number of HTTP requests and global bindings versus vServer bindings has a direct impact on CPU when considering compression. To avoid compression consuming 100% of the CPU restrict it to 25% using the set cmp parameter -cmpbypasspct
The other setting is “CPU load at which to bypass compression: 100%.” You do not want compression policies to consume 100% of CPU. If you set this to 25% on a MPX 11500 or MPX 9700, you will still have significantly more CPU power than a VPX 1000 series with two virtual CPUs and 8 GB of RAM. A virtual NetScaler instance may vary drastically depending on the underlying hardware and to a lesser degree the underlying hypervisor running on that hardware.
The number of HTTP requests and global bindings versus vServer bindings has a direct influence on CPU. To avoid compression consuming 100% CPU restrict this to 25% using the set cmp parameter -cmpbypasspct
What policies are bound globally? Type show cmp global
to reveal the “Classic” policies. Five of ten possible policies have been set, some to COMPRESS and others to NO COMPRESS. This can be misleading.
When you refer back to the GUI you see the same 5 of 10 policies. Of the 5 policies above, two are NO COMPRESS and three are COMPRESS, and the bind point is RES_DEFAULT.
Notice the naming convention in first column “Name.” There are two categories of policies; Classic, with the prefix “ns_*cmp*”, and Advanced, with the prefix “ns_adv*”.
The global configuration defines which policies are processed and which are not. This was changed to ADVANCED using the set cmp command line.
The global binding can be misleading in that by default it is enabled and bound globally. If you have not defined a content switch or virtual servers, the impact is null. If a content switch or virtual servers are configured and compression is enabled at the service level, the global bindings take effect immediately.
Use show cmp policies
and scroll down to Advanced.
Inspect the ns.conf file and verify the bindings:
Now, when two web servers are added and a service group created, a load balanced virtual IP or Content Switch can be bound to it; using the NetScaler GUI > Traffic Management > Load Balancing > Servers > “Add”
Add the servers as IP Addresses bound to those internal resources. NetScaler uses a SNIP IP so it can communicate with the subnet 10.10.10.0/24. A SNIP or subnet IP is assumed to exist for purposes of this article.
The traffic is HTTP, so you need two services. Bind a service to a server and then bind a service to a VIP or content switch. Alternatively, you can create a “Service Group” with like services.
Using the Netscaler GUI > Traffic Management > Load Balancing > Services > “Add”
Add “http-server-1” and “http-server-2” selecting “Existing Server” using protocol “HTTP” and port “80.”
Now there are two servers defined and two services for those servers as HTTP.
Many more such servers could be added in the future, so instead of binding services to a Content switch I prefer to use the “Service Group” option. Using the NetScaler GUI > Traffic Management > Load Balancing > Service Groups > “Add”
Name the Service Group “sg_http_ms_application”; in this case they are servers hosting Microsoft Word and Excel content. We want to compress that content on the NetScaler to improve the end-user experience when the user clicks a link from the client side browser.
Clicking “OK” adds the services corresponding to the servers added previously. A real scenario is thousands of servers and corresponding services leveraging a single content switch subdivided to virtual servers.
Enable “Compression” on the Service Group. Now all of the servers in that group have compression enabled.
Now add a load balance VIP or content switch for this service group. Using the NetScaler GUI > Traffic Management > Load Balancing > Virtual Servers > “Add”
Use a name that resembles the services; “lbvs_iis_microsoft_app_co
ntent”, using the HTTP protocol, assign the IP Address previously allocated for this purpose, and use port 80.
Click OK and bind the service group created previously.
Service Group Binding > Click to Select > Click the “sg_http_ms_application”
(the service group created earlier) > Select > Bind >
and then click Continue
In this abbreviated, basic example, we added two IIS servers hosted in the backend and associated those servers to a service of HTTP protocol as a “Service Group” associated to a Virtual IP Address. This can easily be thousands of servers.
You have the option of using DNS to assign an FQDN for that IP, and I recommend this over using IP address. The DNS name is particularly important as it pertains to web coding. IP addresses change and should never be referenced directly in code. For example, I would not use http://10.10.20.100
but instead http://vip.mscontent.mycompany.com
Other factors such as a “split-DNS” have an impact where this is from an internal IP range, but we saw earlier that the content switch can redirect to any virtual server created on the NetScaler. The power of the content switch is too broad to discuss in one writing, but consider having hundreds of web servers divided by content and having corresponding Virtual Servers and a single IP address bound to a single content switch applying policies that examine the host header (FQDN) and seamlessly redirect content to any of those Virtual servers.
Compression is enabled at both the global and service levels, so we can now monitor statistics using the GUI or using the command show cmp stat
The following table provides information on the default Classic and Advanced policies:
Picture Source: http://docs.citrix.com/en-us/netscaler/11/optimization/http-compression/configuring-http-compression.html
Compression is available with Enterprise or Platinum licensing and is not enabled by default.
Netscaler Product Matrix
Does this shared knowledge provide value? If this article has value please click on "Good Article" button to your right
. If you value the knowledge shared please indicate this with one click to the right. I appreciate you taking time out to read this contribution.