nginx / gui-v2-wasm: deliver the wasm file gzipped

[mpvader]

Short version:

The WASM file is (now) 30MB. Zipped its approx 11MB. Nginx can deliver that zipped to the client, but "on the fly" gzipping it takes a long time. And also a lot of cpu, see bottom for how long and how much on Cerbo.

So, final solution, add a pre-gzipped version of the wasm file, and configure nxinx to use that.

Result is that the download is reduced from 30MB to 11.7MB, and (here on the local network in Groningen, LAN to WiFi) the time from 2.8 to 1.17 seconds.

Details:

Before adding application/wasm to the ngnix gzip config:

After adding that to the nginx gzip config; note how number of MBs has nicely improved downwards, but time is higher

And, finally, here is the result when the .gz file is already available on disk:

As a side note, on a Cerbo it took 50 seconds to gzip the file, takes approx 45% CPU:

root@einstein:/var/www/venus/gui-beta# time gzip -c ./venus-gui-v2.wasm > ./venus-gui-v2.wasm.gz

real    0m50.716s
user    0m40.225s
sys 0m1.015s

[mpvader]

To make it happen:

1. Add the gzipped file on disk, right aside the non gzipped one (or instead of the non-gzipped one even). Read https://docs.nginx.com/nginx/admin-guide/web-server/compression/#:~:text=Enabling%20Compression,and%20list%20the%20additional%20types. for details.

2. Add application/wasm to the list of encodings that nginx gzips.

3. Enable static gzipping. The module is already included in the nginx build, so no need to worry on that.

Added by Dirk-Jan:

4. If we only store the gzipped one, adjust vrmlogger to report the sha256sum of the gunzipped version.

[dirkjanfaber]

Created three patches for this:

• meta-victronenergy, branch faberd/issue-1146
• meta-victronenergy-private, branch faberd/issue-1146
• vrmlogger version v2.291

And put them on the same TODO entry for the next candidate

[mpvader]

Hi I see your unzipping that file in vrmlogger: have you checked the duration and load of such operation, especially on a slower device, such as ccgx?

[dirkjanfaber]

It is only done once per boot of the system. The CCGX takes about 3.8 seconds to unpack. I'd say that is not too bad.

Possible alternative would be to add the sha256sum in a file during the gui-v2 installation and use the contents of that file for vrmlogger.

I propose using the current method for the next candidate. If that performs poorly on the ccgx, we adjust it to use the alternative method.

[dirkjanfaber]

Alright, modified the code to create a SHA256SUM.txt file that vrmlogger (from version v2.292) can read, containing the sha256sum of the non-gzipped webassembly file. Also adjusted the nginx configuration to only use the gzip_static module for webassembly files.

All modern browsers support gzip, but if we encounter ones that don't, we need to add the non-gzipped version of the file to the device as well.

[mpvader]

Agree to not including the non-zipped version. 30MB is quite a lot in Venus OS size of things; increasing download times etc etc.

and as discussed please rename file to [filename].sha256 or something similar.

[dirkjanfaber]

Adjusted the filename to be venus-gui-v2.wasm.sha256. As its contents is still in the default checksum format, it should be clear that it is the sha256sum of the non-gzipped file.

7d97849f3ef3b2a0539b0c2e839271866a3596450037680460b858ffdaf2cca4  venus-gui-v2.wasm

Izak adjusted vrmlogger for this; all changes updated on the TODO.

[mpvader]

fyi @dirkjanfaber same/similar problem on another app on Venus OS.