JupyterLab is very slow to access when the server is started inside a shared folder

JupyterLab
1

Hello,

I am trying to start the Jupyter Lab (v3.0.9) inside a shared folder (a S3 bucket mounted as a file system with goofys).

However, the frontend is very slow to access: it takes something like 20 seconds before everything is rendered. (As a comparison, the classic notebook accessed with /tree does not suffer from this problem).

Some of the routes are particularly slow, for example (non-exhaustive):

  • /api/nbconvert
  • /lab/api/settings/@jupyterlab/shortcuts-extension:shortcuts
  • /lab/api/settings/@jupyterlab/docmanager-extension:plugin

When I check the log of the mounted S3 bucket, I see that more than 1000 requests are made during the frontend rendering, and most of them try to access folders that do not exist, for instance

  • base
  • lab
  • latex
  • script
  • rst
  • …

Is it normal that those requests are made? Do you know how could I accelerate the rendering?

Thanks!

2

I experienced the same issue when the $HOME directory is mounted using an NFS storage. The issue is that these shared storage have important latencies compared to traditional file systems.

I would be happy if anyone knows if there is an option to limit the number of requests to the $HOME directory during the loading of Jupyter Lab.

3

FYI, when JLab starts, it loads settings data for each plugin. Each plugin has its settings information stored as a separate file on disk - those are the /lab/api/settings/* requests.

Separately, JupyterLab is asking nbconvert for what kinds of conversions it can do to populate the Export menu (IIRC). That is the /api/nbconvert call. When you say there are lots of accesses to folders that don’t exist, are you saying that JupyterLab is making an explicit API request for these, or just that someone is requesting the directory on disk? If the latter, my guess is that the jlab /api/nbconvert call is causing nbconvert to internally scan for possible conversions it can do, and that scan is what is internally attempting to access latex, script, rst, etc. directories?