What are the benefits and pitfalls if you compress all communications between the Altiris Agent and Notification Server?

Products

• Management Platform (Formerly known as Notification Server)

Issue/Introduction

 

Resolution

Question
Altiris recommends (via the Altiris Agent configuration page) to compress communication if the size is above 200KB.

What are the benefits and pitfalls if you select to compress all communication between the Altiris Agent and the Notification Server?

Answer

Benefits of compressing all agent communications:

Network Bandwidth usage and latency in communicating to the Notification Server will be the main benefitor of such strategy (by decreasing 8 to 10 fold).

With the current zip algorithm used by the Agent and Notification Server for inflating and deflating xml strings (client policy, NS Events, Package Snapshots etc) the compression ratio  is between 75% and 85%.

Here is a view of compress xml files used to get an idea of the compression ratio that can be expected (note that this is a view from a file compression software, but this information was also gathered from the Altiris Agent log files):

This means that events smaller than 200KB will transit across the network faster with lower bandwidth usage, as calculated in Table 1. Note that compression ratio used for the 'Size in bytes' > 'Compressed' column was 85%. 

Table 1: Results of compressing NS Event on the network usage

NSE Size	Size in bytes		IP datagrams (MTU = 1500)		Transmission time @ 64 kbps
( in KB )	Uncompressed	Compressed	Uncompressed	Compressed	Uncompressed	Compressed
10	10240	1536	7	2	1.25	0.1875
25	25600	3840	18	3	3.125	0.46875
50	51200	7680	35	6	6.25	0.9375
75	76800	11520	52	8	9.375	1.40625
100	102400	15360	69	11	12.5	1.875
125	128000	19200	86	13	15.625	2.34375
150	153600	23040	103	16	18.75	2.8125
175	179200	26880	120	18	21.875	3.28125
200	204800	30720	137	21	25	3.75
Total	931840	139776	627	98	113.75	17.0625

Note: using free zip utilities we can see that files smaller than 7000 bytes have a compression ratio below 60% and be consistantly over 80% for files above 15KB.

Pitfalls of compressing all agent communications:

Compressing all communications between the Altiris Agent and Notification Server does have some impact (mainly) on the Notification Server, where the NSEvents are received (inflated) and where configuration strings or snapshot strings are build and sent (deflated).

Based on 502 NSE's of various size (from 1KB to 800KB+) taken from a live Notification Server we have calculated the following average compression times per KB and compression times per NSE size:

Table 2: Compression times per KB (1 tick count = 1milli-second)

			Tickcount per KB	Sample NSE
	NSE (size in KB)	"=<10"	0.00ms	31
"10 <"	NSE (size in KB)	"=<30"	0.30ms	236
"30 <"	NSE (size in KB)	"=<100"	0.30ms	152
"100 <"	NSE (size in KB)	"=<200"	0.26ms	46
"200 <"	NSE (size in KB)		0.21ms	28
				483

Table 3: Compression times (average) per NSE Size below 200KB

NS Event size	Compression time (in tick count)
5	0
10	0
15	4.5
20	6
25	7.5
30	9
35	9.1
40	10.4
45	11.7
50	13
75	19.5
100	26
125	26.25
150	31.5
175	36.75
200	42

Note: Calculation were based on information logged by the Altiris Agent after dropping the 502 NS Event samples and changing the Altiris Agent configuration REG_DWORD Delay "Between Events (milliseconds)" to 0 (default is 2000). Shutting all non-vital services and programs allowed us to use the tickcount difference between events to calculate the tick count used to compress events.

The discrepancy between the events sent to the NS and show in the result table comes from 9 of the 40 events smaller than 10KB that took 10ms to be compressed. Given that for each ot these event a number had processed in less than 1 milli-second these 9 events were discounted has invalid result (likely caused by process switching or OS background tasks).


This result can be then translated as a load on the Notification Server expressed in CPU time, assuming that the inflating process takes a similar load as deflating xml string (we currently have no way to calculate decompression time on the Notification Server):

Table 4: example of CPU load for decompressing events received

	Events distribution					CPU time in Second
NSE Count	10KB(25%)	50KB (15%)	100KB (45%)	200KB (15%)		10KB	50KB	100KB	200KB	Total
2,000	500	300	900	300		0.1	3.9	23.4	12.6	40
10,000	2500	1500	4500	1500		0.5	19.5	117	63	200
25,000	6250	3750	11250	3750		1.25	48.75	292.5	157.5	500
50,000	12500	7500	22500	7500		2.5	97.5	585	315	1000
100,000	25000	15000	45000	15000		5	195	1170	630	2000
200,000	50000	30000	90000	30000		10	390	2340	1260	4000
500,000	125000	75000	225000	75000		25	975	5850	3150	10000

Note that the event distribution was decided for this example and is not based on specific studies from live or test systems.