If you use Tomcat in your SAP BO XI environment, one of the tuning / performance enhancement options that you should explore is a compression of an HTML content.
The idea is very simple. Tomcat compresses HTML content (using g-zip) before sending it to user’s web browser. All common browsers (Internet Explorer, Firefox, etc.) then decompress the content to a plain text and use it to render results to a user. Such compression can save huge volume of data being transferred through the network. This in turn can not only save bandwidth but also can increase performance of any web application (Business Objects Infoview included) by speeding up the web page load time.
Good to know
There are few things worth of checking before enabling the content compression though.
Extra load put on Tomcat
Letting Tomcat to do the compression means it needs more CPU cycles to perform the extra work. So if you have many concurrent BO users and Tomcat is already fully utilized serving normal, non-compressed content then you should test really carefully whether enabling compression would not degrade performance rather than improve it.
Web browsers support of HTTP compression
As already mentioned, all modern web browser support the compression. However, you still may want to ensure that Tomcat provides content that users’ browsers understand. Check your web browser for instance here if it supports compression.
The beauty of the content compression in Tomcat is in fact that it’s a built-in feature in Tomcat since the version 5.5. It just needs to be enabled. And this is not a difficult task. Let’s check how it’s done.
The compression is configured in the Tomcat’s server.xml file. Find the XML file in the Tomcat conf folder. If the Tomcat was installed with BOE then the folder is:
<BO install folder>\Tomcat55\conf
Do a backup of the server.xml file before doing any changes.
Open the server.xml file for edit.
Find the non-SSL HTTP/1.1 Connector and add following lines into it:
Save the file and close it.
Restart Tomcat so the changes take effect.
And what these new lines do?
compression=”on” – instructs Tomcat to compress the content
compressionMinSize=”2048″ – the minimal size of a file to be compressed is set to 2KB.
nocompressionUserAgents=”gozilla, traviata” – attribute to disable compression for certain browser types
compressableMimeType – specifies types of files to be compressed because not all file types are suitable for compression
I tested basic actions in Infoview to see the effect of the content compression. Here are the results:
action metric without compression with compression
Infoview login page refresh request count 9 9
bytes sent 9791 9791
bytes received 17797 9810
user login to Infoview request count 12 12
bytes sent 20108 20163
bytes received 77283 25666
navigating to a folder request count 101 103
bytes sent 210362 215036
bytes received 1075870 265223
opening a dashboard request count 7 7
bytes sent 15528 15574
bytes received 627619 622085
opening a report request count 55 60
bytes sent 110660 121660
bytes received 791420 262633
user logout from Infoview request count 15 15
bytes sent 24490 24540
bytes received 22306 11492
As you can see, the volume of data that Tomcat sent to the browser was only the small portion of the original volume. The only case when almost no improvement can be seen is when I opened a dashboard. But that’s expected. Tomcat was not instructed to compress a Flash file of the dashboard.
Please share your experience with the content compression in a BOXI environment in your comments.