Turbocharged RAP

June 21, 2012 | 2 min Read

The release of the RAP protocol is an important milestone. The protocol enables native mobile client Apps (in addition to the existing browser client) to connect to the RAP server. In other words, the data is now sent over the network by using JSON instead of proprietary JavaScript.

One thing we noticed, was that the server responses were not compressed anymore by the server. On company networks this might not really matter, but if you’re using 3G or an unreliable WiFi connection, package drops might cause frustration among users.

To solve this issue you need to reduce the data that is transferred or even better, fit it into one IP package. You can do this by enabling GZip compression on the server.

There are two important things to watch for -

  1. Make sure the server compresses the JSON responses. RAP uses the mime type “application/json” for the protocol messages.
  2. Depending on your server you need to explicitly turn on compression and/or configure when to compress the content (ie. if the content is bigger then a specified size).

For Tomcat, the configuration looks like this:

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" **compressableMimeType**="text/html,text/xml,text/plain,**application/json**" **compression**="**1200**" />

For Apache, the configuration (/etc/apache2/mods-enabled/deflate.conf) looks like this:

<IfModule mod_deflate.c> # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 **AddOutputFilterByType DEFLATE application/json** AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/jav ascript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml </IfModule>

In our case we added the “application/jsonmime type and configured our server to compress responses with 1200 bytes and more. If you’re considering having compression always on, think again. Most data under 1000 bytes will become bigger when it is compressed. And, if the data - compressed or not - is not bigger then 1500 bytes, it will fit in one IP package (see MTU). In fact, this will speed up the client-server communication. Your users will experience less latency and less impact from package drops.

In one test run, we created an initial JSON response with about 20.000 bytes. With compression enabled, we reduced that to only 2.000 bytes that were transferred! The result was 10x less data or a transfer that was roughly 10x faster.