View RSS Feed

Development Team Blog

Configuring HTTP Compression for DataFlex WebApps

Rating: 283 votes, 4.99 average.
A standard feature of the Internet Information Server is HTTP compression. This module is available to optimize the performance of web applications by compressing HTTP responses that are sent to the client. The goal is to decrease the size of the responses to allow faster network transmission. Of course this has the side effect that the CPU usage increases on the server (and on the client). So we are trading CPU usage against bandwidth here. This means that HTTP compression doesn't always make your application perform better. The positive effects will be larger on slower networks and especially on WebApps running over the internet. If your server is already short on CPU power it might actually decrease the performance.

Note that all modern browsers support HTTP compression and the fallback system is pretty good. Browsers that support HTTP compression tell the server that they do by sending an HTTP Header with each request. This header called Accept-Encoding actually contains the supported compression types (usually GZIP and deflate). If this header is not found or doesn't contain the right type the server will send the data uncompressed.

More details on HTTP Compression can be found in this blog: http://weblogs.asp.net/owscott/archi...-how-much.aspx

Static vs Dynamic
The HTTP compression module is actually split into two parts. There is static compression which compresses and caches static files that are requested by the client. Examples of these are HTML, JavaScript and CSS files. These files are sent to the client as they are found on the hard drive without being processed by the server. This allows the compression module too cache compressed versions of these files which reduces the overhead when the file is requested for a second time. Enabling this in a production environment is pretty much a no brainer as there is almost no overhead once an application is running for a longer time.

Dynamic compression is the compression of content that is generated on the server when a request comes in. Examples of dynamic content are ASP scripts and DataFlex Web Service responses. Because the responses are generated when a request comes in the compression module cannot cache the response. This means that the data is compressed on the fly which results in extra CPU processing time for each request.

Installing HTTP Compression
Like the other standard parts of the Internet Information Server the dynamic compression module can be installed from the "Turn Windows features on or off" dialog that can be accessed from the control panel. The options "Dynamic Content Compression" and "Static Content Compression" can be found under "Internet Information Services > World Wide Web Services > Performance Features". The screenshot shows these two options.

After the features are enabled we should see the compression icon in the Internet Information Services (IIS) Manager as shown in the screenshot below. The compression can be enabled / disabled on all levels of IIS (Server, Website and Virtual Directory).


Enabling static compression
Enabling static compression is pretty straight forward. In this blog we will show how to do this for a specific virtual directory like the WebOrder_17_1 of the WebOrder sample. So in the IIS Manager we go to WebOrder_17_1 and double click the compression icon (as shown in the previous screenshot). There we check "Enable static content compression" and click Apply to save the changes.


Confirm that it works
Changing this setting probably won't make a noticeable difference in our test environment. To make sure that it is working we are going to use FireBug which is an extension of FireFox. In FireBug we can trace all the HTTP requests that are made by the browser when running a WebApp. It will also show details like the size of the HTTP responses. In the screenshot below we have opened FireFox, enabled firebug and navigated to http://localhost/WebOrder_17_1/. On the Net tab we see an overview of all requests that are made. The screenshot was made before Static Compression is enabled. We now see that the biggest file loaded to the client is the JavaScript engine (df-min.js) with almost 300 KB.


After we have enabled static compression we will reload the page a couple of times using ctrl - f5. Note that reloading multiple times might be needed to let the compression module determine that a file is requested on a regular basis before it will compress it. Now we will see that the sizes displayed by FireBug go down dramatically. The screenshot below shows the same requests with static compression enabled. Note that df-min.js is compressed from 300KB to 60KB.


Sometimes browser caching might prevent us from seeing these results. That is one of the reasons why FireBug allows us to disable the browser cache as it is running. The screenshot below shows where the "Disable Browser Cache" option can be found in FireBug. Try again with this option enabled if the results do not change.


Enabling dynamic compression
Dynamic compression requires a bit more configuration. Not only does it need to be enabled, we also need to make sure that it recognizes the framework its AJAX Calls to the DataFlex WebService as dynamic content it can compress. This requires us to change some of the advanced settings of this module. These settings can be found in the IIS Manager in the configuration editor that we find at the server level. The screenshot below shows where to find it.


In the configuration editor we select the section "system.webServer/httpCompression" and then click at the prompt button after the option "dynamicTypes".


In the collection editor that comes up we can configure which response types are compressed dynamically. This works on the mime type that is used for the response. In Web Framework WebApps the JavaScript engine is accessing the DataFlex WebService using JSON. DataFlex returns "application/json" as the mime type so we need to add "application/json" to this list as enabled.


Don't forget to click Apply in the Configuration Editor after closing the Collection Editor. Now we can enable dynamic compression on the WebOrder_17_1 virtual directory by opening the compression settings after selecting this virtual directory.


Confirm that it works
To confirm that the dynamic compression works we will to look at the AJAX Calls using FireBug. To make this a bit easier we can filter the HTTP requests shown on the Net tab by clicking the XHR button (XHR stands for XmlHttpRequest). Almost every action in the WebOrder sample results in an AJAX Call. The screenshot below shows the calls for a couple of finds on the Order screen after dynamic compression is enabled.

As the sizes here depend on the state of the application we will look at the request itself to confirm that dynamic compression is enabled. If we expand one of the calls and look at the headers tab we will see that the response contains a header "Content-Encoding" with the value GZIP. This confirms that dynamic compression is now properly enabled.

Note that FireFox has sent the "Accept-Encoding" header to tell the server that it accepts compressed responses using the GZIP and deflate algoritms.
Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	9 - Collection Editor Mime Types.png 
Views:	4812 
Size:	46.5 KB 
ID:	7181   Click image for larger version. 

Name:	12 - FireBug Response Header.png 
Views:	4559 
Size:	41.5 KB 
ID:	7446   Click image for larger version. 

Name:	11 - FireBug After Dynamic Compression.png 
Views:	4213 
Size:	24.7 KB 
ID:	7447   Click image for larger version. 

Name:	10 - Enable Dynamic Compression.png 
Views:	4243 
Size:	101.2 KB 
ID:	7448   Click image for larger version. 

Name:	8 - Configuration Editor Dynamic Types.png 
Views:	6391 
Size:	110.9 KB 
ID:	7449   Click image for larger version. 

Name:	7 - Configuration Editor.png 
Views:	3926 
Size:	109.4 KB 
ID:	7450   Click image for larger version. 

Name:	FireBug Disable Cache.png 
Views:	4369 
Size:	8.7 KB 
ID:	7451   Click image for larger version. 

Name:	FireBug with Static Compression.png 
Views:	4157 
Size:	27.3 KB 
ID:	7452   Click image for larger version. 

Name:	FireBug Before Static Compression.png 
Views:	4400 
Size:	85.9 KB 
ID:	7453  

Click image for larger version. 

Name:	Enabling Static Compression.png 
Views:	4630 
Size:	104.2 KB 
ID:	7454   Click image for larger version. 

Name:	Compression In IIS.png 
Views:	4359 
Size:	137.2 KB 
ID:	7455   Click image for larger version. 

Name:	Installing HTTP Compression.png 
Views:	4439 
Size:	121.9 KB 
ID:	7456   Click image for larger version. 

Name:	Screenshot IIS Static Content.png 
Views:	3962 
Size:	57.6 KB 
ID:	7457  

Updated 17-Feb-2014 at 04:26 AM by Harm Wibier

Categories
Uncategorized

Comments

  1. Samuel Pizarro's Avatar
    Hi, don't know what happen, (maybe after the site version was updated some weeks ago) but I can't see most of the screen-shots on this blog !
    All pictues (except one) are showing as a little square with an X inside.
  2. Harm Wibier's Avatar
    Should be fixed now...