After the changes, restart the web server (Apache, Nginx, or lighttpd) and check the logs for errors.
In a basic test with compression modules, we're able to identify that we have a considerable gain in file size. The following table shows the level of compression and page load times (tr_staus.php is the page that shows the status of the triggers) on a virtual server with 500 active triggers:
|
Compression modules |
Apache without mod_deflate |
Nginx without gzip |
lighttpd without |
Apache with |
Nginx with gzip |
lighttpd with |
|
Size |
1.2 MB |
1.2 MB |
1.2 MB |
51.5 KB |
51.5 KB |
51.5 KB |
|
Time |
~5 sec |
~6 sec |
~6 sec |
~5 sec |
~3 sec |
~4 sec |
Of course, the tests may have different results with different hardware. The focus is on exemplifying how compression impacts the visualization of Zabbix screens.
If you don't have access to the web server settings (to enable the modules), you can add a small piece of PHP code in each .php file in Zabbix, and force compression of such files. Particularly, this alternative seems feasible only in extreme cases and when you cannot use the preceding tips.
The following code can be added to the first line of PHPs in Zabbix to perform compression:
ob_start("ob_gzhandler");