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

book

Article ID: 179825

calendar_today

Updated On:

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.

Attachments