-
Notifications
You must be signed in to change notification settings - Fork 11
Description
User story
As a [user], I want to have compression enabled (or the option to), so that large requests/responses are easier to upload/download on slower connections.
Description
We seem to handle some compression on the manager under the following conditions https://github.com/openremote/openremote/blob/3cc20bce9ed525879f6e96ad331d4842847b01b6/container/src/main/java/org/openremote/container/web/WebService.java#L276. This does not apply to the bundle.js file of the manager, but it does seem to apply to requests like getValueDescriptorSchema if larger than 5kB.
Having this on a proxy level would help centralize where compression is applied. With these changes we also want to ensure frequently/recently (previously) requested data is cached after compression, to reduce compute load (this may be built in to haproxy).
We may want to consider being able to toggle the current compression on the manager (in a separate issue), as the local server/cluster network should be fast enough and thus probably doesn't need this.
Acceptance criteria
- Must support common content-encodings, like
gzip, deflate(and shouldzstd).- Compression should be applied based on the
Accept-encodingheader. - Already compressed content should not get compressed again.
- Compression should be applied based on the
- We should cache compressed data on haproxy (or somewhere else if not possible) to reduce compute.
Technical details
It would be nice if we can get zstd supported, as it improves upon the performance of gzip and it somewhat recently got supported by multiple major browsers (see https://caniuse.com/?search=zstd). ATM, haproxy has an open issue for zstd support.
See https://www.haproxy.com/documentation/haproxy-configuration-tutorials/performance/compression/