PLANTA Server and PLANTA Client communicate via an XML protocol. As a result, a well defined interface is given, ensuring stable interoperability. However, due to the self-describing and readable nature of the language - XML files are quite large in relation to the actual amount of user data. This is a minor issue in intranet situations, where a performant network infrastructure is given. However, if network congestions exist, the message size may lead to a significant loss in performance, especially for greater data volumes. Network congestions of this type occur, for instance, if the clients communicate from remote stations via a PLANTA Server running in the central computing center. Since the XML format contains high redundancies, compression may help to reduce the size of the message significantly. Instead of sending the XML messages directly through the network, they are comprimized in PLANTA, using a deflate algorithm. By means of compression, more than 90 % of the data volume sent can be saved. The efficiency of the algorithm can be adjusted through a compression ratio. Here, one has to weight the computing time used and the resulting message size: for low compression ratio, only few computing time is needed but the message size is greater; for high compression ratio, the reverse is true.

Implementation and Configuration

It makes sense to use compression and encryption on the same level. Many implementations of the TLS protocol support compression via zlib (Deflate). However, the .NET implementation of TLS does not support this, so an additional compression layer has become necessary. Here, the client as well as the server use the deflate procedure. The configuration must take place on both sides. When connecting the client with the server, the communication partners negotiate whether compression is to be carried out. Only if both client and server, are configured for compression, they communicate in a compressed way after negotiation. Deflate allows you to specify a compression ratio which can be adjusted from 0 - 9.

  • 0: no compression. Due to the zlib format overhead, the data volume to be transferred gets bigger here.
  • 1: fastest compression
  • 2 - 8: Intermediate level, with default level 6
  • 9: best compression

For client and server, the compression ratios can be specified independently. If no compression ratio is specified in the configuration file, ratio 6 is accepted here as well.

Measuring Example

The following diagrams illustrate the potential savings by compression. Here, only the user data volume is allowed for; on a TCP packet level, the low number of packets when using compression may lead to further improvements in data volume.

Project Workflow

For all test cases, a demo data system was used. Project 4711 was selected via user R41 (Multi-project manager). All modules of the project panel are selected now in order to get information from every module. After that, a status report was created. The client was closed subsequently. In the first and second illustration, the total number of messages sent by the server is displayed on the x-axis. It varies from run to run since the sequence mentioned above was carried out manually and a varying number of events was prompted. However, this hardly has any effect on the size of the data sent, which is displayed on the y-axis. The curves shown in the first image are also included in the second image but here, they are contrasted with further configurations with selected compression ratios.

Total transfer volume uncompressed and compressed (compression ratio 9)

 

Comparison when using different compression ratios

 

For server based hyperlinks, a greater data volume is incurred since these objects (e.g. Word documents) are sent from the database to the client. Here, great savings are not to be expected since many file types are already internally compressed. However, the binary data is embedded via a base64-codec into the XML message, so that 4/3 of the actual data volume must be transferred. For compressed data, this results in a potential saving through compression of 1/4 of the data volume. For uncompressed data like e.g. log files, a far higher portion may be achieved.

Compression result with different file types

Compression Scenarios

In most scenarios, compression is useful since it reduces the data volume to be transferred significantly. Additional compression can be skipped if a compressing VPN tunnel is used since compression is included in the encryption layer. However, the additional effort is not so high, that it becomes necessary to turn compression off. Compression can only be turned off for individual clients so that e.g. a client in a remote station, connected via compressing VPN, does not use compression, while another client in another remote station communicates with compression.

See also : Message Compression: Configuration