HTTP performance

[mlucool]

As it stands today, jupyter-server appears to be suboptimal from a web-performance point of view. There are a few reasons for this, but I think some of this is due to 1) lack of HTTP2 (longstanding torando issue) and 2) static assets are being served via python.

The move to federated extensions puts the knowledge of where to find JS into the server itself making it harder to just throw an apache/nginx in front as the locations of js files are no longer fixed. In addition federated extensions pushed the build-chain to continue to modernize. Modern webpack outputs many smaller, chunked assets which is great for HTTP2 but actively problematic for HTTP1 (head of line blocking etc). The move to nginx/apache can allow us to add things like higher levels of compression (and compression types like brotli) and improved caching (both via headers and keeping the JS in memory).

This topics is being explored in jupyter-server/jupyter_server#312. We hope to have a clear proof of concept in the next couple of months to show the effect of having nginx proxy static assets. While somewhat untested, but we expect localhost deployments won't see any difference, but when users sit far from their Jupyter server they will have a noticeably better experience.

I am logging this as an outcome of the jupyter-server meeting (notes), where we thought it would be useful to see how jupyverse performs.

CC @Zsailer @kevin-bates @divyansshhh

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[davidbrochart]

Thanks for opening this issue @mlucool.
Indeed it would be interesting to see how jupyverse compares to jupyter-server in terms of performances. Even for tracking the performances of one of these servers over time, it would be great to have a dedicated project.
It looks like jupyverse could use hypercorn as its ASGI server, instead of uvicorn. The former supports HTTP/2, while the latter doesn't.