What are the benefits and pitfalls if you compress all communications between the Altiris Agent and Notification Server?
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:
NSE Size Size in bytes IP datagrams (MTU = 1500) Transmission time ( 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 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). Table 2: Compression times per KB (1 tick count = 1milli-second)
Tickcount per KB Sample NSE
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
@ 64 kbps
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.
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:
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.