Can't find what you are looking for? Try these pages!

Blog

Configuring HTTP Compression for DataFlex Web Apps

December 19,2013
By Harm Wibier

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.

Installing HTTP Compression

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).

Compression In IIS

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.

Enabling Static Compression

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.

FireBug Before Static Compression

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.

FireBug Disable Cache

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.

10 - Enable Dynamic Compression

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

8 - Configuration Editor Dynamic Types

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.

9 - Collection Editor Mime Types

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.

10 - Enable Dynamic Compression

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.

11 - FireBug After Dynamic Compression

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.

12 - FireBug Response Header

Note that FireFox has sent the "Accept-Encoding" header to tell the server that it accepts compressed responses using the GZIP and deflate algoritms.