second-by-second stuttering instead of continuous data stream

[jhgoebbert]

Bug description

It seems as if a continuous data stream of a web application is forwarded in larger data chunks when using jupyter-server-proxy. This is a major problem for some web services that cannot live with high latency.

Actual behaviour

The effect can be seen in the server proxy jupyter-xprahtml5 for the html5 web client of the remote desktop software Xpra, where the video stream stalls significantly every second (see below) - unfortunately, this makes it not a proper remote desktop solution.

Expected behaviour

The assumption that it is jupyter-server-proxy which introduces this second-by-second stuttering can be seen in the comparison with a stand-alone Xpra-setup (on the same machine). Here, the html5 web client only communicates via an SSH tunnel with the same configured Xpra server without jupyter-server-proxy in between. The video playback is smooth and does not stutter.

Personal set up

I am running JupyterLab 4.2.1 with jupyter-server-proxy 4.1.2 on a Rocky Linux 8 cluster.
The laptop is connected through an ssh tunnel and runs Firefox (also tested with Chrome) on Windows 11 (other users see this phenomena also on Linux clients).

More details on the installation of JupyterLab can be found here:
https://github.com/easybuilders/JSC/blob/2024/Golden_Repo/j/Jupyter-bundle/Jupyter-bundle-20240520-GCCcore-12.3.0.eb

[manics]

Unfortunately it's not a straightforward fix:
#479 (comment)

[jhgoebbert]

@manics Oh, that won't work, because of our RewriteableResponse implementation does not read good. 🤔

[jhgoebbert]

Many thanks to @jwindgassen.
The cause of the stuttering shown above is a Prometheus metrics of jupyter-resouce-usage which blocks tornado's main thread.
jupyter-server/jupyter-resource-usage#123

Setting c.ResourceUseDisplay.enable_prometheus_metrics = False fixes the problem.