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 -
- Make sure the server compresses the JSON responses. RAP uses the mime type “application/json” for the protocol messages.
- 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"
For Apache, the configuration (/etc/apache2/mods-enabled/deflate.conf) looks like this:
# 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/rss+xml
In our case we added the “
application/json” mime 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.