FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Intermediate

What should the Compression Level be; what is its effect on CPU? ​

Short answer

Compression Level is selected from Default (saved as Level 1) and Level 1–Level 9; as the level increases, the response shrinks more but the processor load increases. Low levels (1–3) are suitable for high-traffic sites, medium levels (4–6) for general use, and high levels (7–9) for cases where bandwidth is critical and traffic is low. TR7 does not place a separate ceiling on the processor usage of compression. A level change restarts the vService.

How Does It Work? ​

The compression level determines how much effort the compressor makes for a smaller output. At low levels, the response is shrunk quickly and with little processor; at high levels, each additional level spends noticeably more processor for a few percent of additional gain (the effect of the level).

LevelCompressionProcessorSuitable environment
Level 1–3LowLittleHigh traffic, low processor capacity (environments with low CPU capacity)
Level 4–6MediumMediumGeneral web sites (API services)
Level 7–9HighA lotLow traffic, expensive or slow connection (static content services)

The effect of the level varies according to the response type; on small API responses, high levels provide little gain (API services).

Compression Level in TR7 ​

  • Where: Load Balancer → Profiles → Compression → right-click on the profile row → Edit → Compression Level → Save.
  • Defaults: The Default option in the form is not a separate level; when the profile is saved, it is stored as Level 1. The built-in Default Profile used when Compression is checked on the vService is also Level 1. In WEB-CLI, if --compressionLevel is not written, the level is 1 (WEB-CLI fields).
  • Effect of the change: Changing the level and turning Compression on and off on the vService (binding the profile to the vService and removing it) restart the vService, and open connections drop (When does a change I make take effect; does it go live as soon as I save it?). The change is made in a maintenance window. If the profile is used in more than one vService, all of them restart; the Used in tab in the preview is checked beforehand. In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
  • There is no processor limit: Compression is not throttled on its own when the processor gets busy (recommended values); the processor resource of the vService is managed with QOS.
  • Monitoring: The vService CPU Usage graph on the System tab of the vService dashboard and the Compression graph on the HTTP Frontend tab (Bytes Before Compression / Bytes After Compression) are monitored together. The level is increased gradually; if the processor increase grows faster than the size gain, the previous level is restored.

Common Misconceptions ​

  • "Level 9 is always the best." While the gain drops to a few percent, the processor cost increases noticeably.
  • "A level change is uninterrupted." When the level is saved, the vService restarts; it is changed in a maintenance window.
  • "The processor load depends only on the level." The load also depends on the amount of compressed traffic and on the File Types list.

How it is done in the documentation

Related questions