We have shown that using xhr via http2 in a worker is faster, however we haven’t shown how much faster it is when gzip is present. The in javascript gzip should take CPU cycles, when these are performed on the worker then it should show a larger improvement in offloading to the worker. GZIP will have the biggest performance improvement on large message sizes.
Note, the current test backend system on this repo is VERY slow on sending large payloads over the WS stream library. This is caused by 4k chunking on the websocket frames AND MAYBE other things (TCP_NO_DELAY not being set). If we use the in repo backend for benchmarking then we should increase the WebSocket frame size to 64k.
hthetiot
commented
6 years ago
We have shown that using xhr via http2 in a worker is faster, however we haven’t shown how much faster it is when gzip is present. The in javascript gzip should take CPU cycles, when these are performed on the worker then it should show a larger improvement in offloading to the worker. GZIP will have the biggest performance improvement on large message sizes.
Note, the current test backend system on this repo is VERY slow on sending large payloads over the WS stream library. This is caused by 4k chunking on the websocket frames AND MAYBE other things (TCP_NO_DELAY not being set). If we use the in repo backend for benchmarking then we should increase the WebSocket frame size to 64k.