Using Tuxedo message compression - part 2

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Gary Jones's Blog | March 12, 2008   6:02 PM | Comments (0)

The Tests

A simple application consisting of a client and server was set up. Four various sized VIEW32 buffers were created and used. I chose VIEW32 because I wanted to include both string and non-string data and because the size of the buffer is fixed.

Three sets of tests were performed for each of the VIEW32 buffers:

1. Set the server so that it delays for 20 seconds prior to returning the received buffer.

Run two clients.

Whilst the first clients request is being processed the buffer from the second will be observable on the servers message queue.

2. Set the server so that it returns the received buffer immediately.

Run a single client which makes 1000 service calls and time the client using the time command.

3. Set the server so that it returns the received buffer immediately.

Run a single client which makes 10000 service calls and collect full sar(1) statistics during the run.

The tests were repeated for each possible setting of TMCMPLIMIT and TMCMPPRFM as in the following table:

The Results

Here we can see that the average number of bytes placed on the server's message queue decreases for higher compression ratios.

Here we can see that the average time taken to compress a buffer increases as the size of buffer increases and more importantly as the setting for TMCMPPRFM increases. It is also evident that the best results are obtained by simply switching compression on.

During the third series of tests, full sar(1) statistics were gathered.

Subsets of information for the following were extracted from the gathered data:

pswch/s

msg/s

scall/s

These subsets were then analysed and the number of time intervals noted.

The following picture shows the resource usage for VIEW3. The other VIEWs had similar looking results.

Here we can see that the average resource usage decreases as the number of time intervals increases.

We can see that the resource usage increases slightly for the first few compression settings and then reduces. The reason the average resource usage reduces is because the number of time intervals to achieve the desired compression, as specified by TMCMPPRFM, increases.

Conclusions

The best results seem to be obtained by simply switching compression on. In addition, it can also be seen that if it is desirable to select a compression setting using TMCMPPRFM then a setting of 5 is the maximum that should be selected before the number of time intervals becomes too costly.

Comments