Jupyterlab too slow to load on slow networks

[AbdealiLoKo]

I am using Jupyterlab deployed on a machine on the cloud. It seems to be too slow to open up the main /lab page when i try to open it on my browser.
Now, my network speed is very slow, so I am OK with it, but I am trying to see how I can optimize it.

I can see that the bundle.js file I have is the biggest file it is opening and that takes about 5 minutes to download. When I manually gzipped the file, I noticed that the filesize reduced to one-fourth the filesize.

I was under the impression that NotebookServer/JupyterLab would be able to auto-handle these sort of optimizations and that it would send the file gzipped as Chrome will accept gzipped files.

Do I need to enable any config to enable this sort of compression or what can I do to enable this ?

Any other suggestions to speed it up would be great too! My target connection I want to cater to is 50KB/sec.

PS: I am using Jupyterhub+Notebook+Lab

[jochym]

Newer lab releases (after 0.29) suffered some slow-down in my experience as well. It was strong enough that I was forced to stop on the 0.29 for "production" until this is resolved. So here is additional data point on this.

[blink1073]

Hi @AbdealiJK and @jochym, as of JupyterLab 0.31 (available as pip install --pre jupyterlab) we are using the uglify WebPack plugin and the bundle sizes have down down substantially.

[jochym]

I'll report any changes when I test on my staging install

[AbdealiLoKo]

I still need to use the earlier versions for my current setup due to a bunch of reasons.

I understand uglify will reduce the size, bit the data usage can be even further reduced by gzipping the file...
Any idea about how I can get the static files auto gripped for data-transfers?
That is a very standard method of file transfer I thought

[jochym]

I have checked 0.30.6 with 0.9.0 and it is still unusably slow on my local system - with google drive notebook. At the same time I am working remotely on 0.29 + 0.8.0 so this is a definitive regression.
I cannot check 0.31 + 0.10 at the moment.

[blink1073]

We could use the WebPack compression plugin, but I'm not sure how to configure tornado to serve compressed files.

[jochym]

Additional datapoint: 0.31.2 has the same issue - slow loading from remote server. It is slightly better but definitely not fixed. Particularly with google-drive hosted notebooks (jupyterlab/jupyterlab-google-drive#113), but it is bad with server-hosted notebooks as well.

[AbdealiLoKo]

https://stackoverflow.com/questions/16124908/python-tornado-compressing-static-files 😄

It's supposed to be very simple to implement the compressed static file sending - although I've only done it for django and nodejs and not tornado.

[jochym]

Just to report: 0.31.5 got usable again. I would not say it is fixed but it is much better. We can use JL witth google drive again without frustration.

[zcattacz]

nginx gzip module support gzip on proxfied respond. http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_proxied
Check it out if it you can set it up, this might be the quickest the way to add gzip without changing anything.

[zcattacz]

I have just setup jupyter on server, behind a nginx revser proxy as gateway.
if you are interested in nginx/gzip, try this:

# ~/.jupyter/jupyter_notebook_config.py

c.NotebookApp.base_project_url = '/jupyter/'

#/etc/nginx/nginx.conf
...
... defaults settgings ...
...
http {
    gzip                on;
    gzip_http_version   1.0;  # minium version for gzip to be turned on.
    gzip_types          text/json text/javascript application/xml text/css text/xml application/json application/javascript;
    gzip_proxied        any;
    
    # https://www.nginx.com/blog/websocket-nginx/
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        # external port
        listen          1100;  
        server_name     localhost;
        if ( $request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$ ) {
            return 405;
        }
...
        location ~ ^/jupyter/ {
                # local jupyter instance listening on port 19999.
                proxy_pass  http://127.0.0.1:19999;
                # jupyter complains about host, orgin mismatch & cross domain requests, 
                proxy_set_header Host "127.0.0.1:19999";
                proxy_set_header Origin "http://127.0.0.1:19999";
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
        }
}

It is faster, the initial two >1Mb big .js file, adding together is <1Mb through nginx.
Judging from the response header, websocket seems also have gzip enabled.
Didn't test any notebook, but the intial bootstrap (without cache) is indeed a lot faster.

It's also possible to limit the concurrent request rate and bandwidth.
https://www.nginx.com/resources/admin-guide/restricting-access/
Don't know if they will help mitigate slow line.

[jasongrout]

Our recent upgrade to webpack 4 split our huge js bundle down into several smaller bundles. Is this still an issue with whoever was having issues above?

[ivanjz93]

Our recent upgrade to webpack 4 split our huge js bundle down into several smaller bundles. Is this still an issue with whoever was having issues above?

Hi, I use the latest docker image of datascience notebook, but there is still a huge js. And it took about 20 seconds to load it on a remote chrome.

[flixr]

My vendors~main.xxxx.js is larger than 100MB and is not even cached, see #5558

[jasongrout]

@flixr - what is your jlab version, and what plugins do you have installed?

[flixr]

Using jupyterlab 1.0.1 with quite a view plugins, see attached Dockerfile (uses https://github.com/jupyter/docker-stacks/blob/7a3e968dd21268c4b7a6746458ac34e5c3fc17b9/scipy-notebook/Dockerfile as base)

Dockerfile.txt

[jasongrout]

That is a lot of javascript you are bundling up in jlab with all those plugins. Thanks for being more specific about it.

[flixr]

Yeah, I was actually quite surprised that it amounts to so much....

[ian-r-rose]

I've also been seeing some very large JS bundles, though not quite 100 MB. Part of this could be mitigated by doing a production build jupyter lab build --dev-build=False in your docker file @flixr, but we should also probably establish some best practices around lazy loading for extension authors so that the initial bundle is less punishing to load.

[flixr]

@ian-r-rose thanks for the info, will try with --dev-build=False and see how big it is then.
But my main concern is actually that this js bundle is not cached and hence downloaded every time, see #5558
Any idea why Cache-Control is set to no-cache in the response headers?

[flixr]

I didn't have any luck with --dev-build=False: after 2h it ran into our CI timeout....

[vidartf]

In my experience, when you have bundle sizes / build times such as this, it is due to large amount of duplication (the same dependency tree included multiple times due to incompatible version dependencies).

No matter the cause, this should help you troubleshoot:

• Run jupyter lab paths. Open a terminal and change into the Application directory.
• Go into the subfolder staging.
• Run jlpm build:stats
• If you have a recent version of npm/node, run npx webpack-bundle-analyzer stats.json. If not, run:
  • jlpm global add webpack-bundle-analyzer
  • webpack-bundle-analyzer stats.json

This should allow you to see what is taking up space in your bundle (and/or share it with us). Try to identify any repeating patterns (e.g. a large package being included multiple places). If you find any such packages, please run jlpm why packagename to see more details about why they are included.

[flixr]

Unfortunately I'm not really familiar with node and the like...
When I run npx webpack-bundle-analyzer stats.json I get:

Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/0.afe80b48d434cea8c9f3.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/1.ba120c19ebe15dc143e1.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/2.658bde32642991e933b8.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/3.2e2682ca21e208f2567b.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/4.8af58ff2b4b0e8005757.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/main.42749e117c9447feabfd.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/pdfjs.ce08e4c644a9f156fdb2.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/vendors~main.3a8ea8f483a5a9147e64.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/vendors~pdfjs.4afe09c1e8202d391905.js": no such file
Error parsing bundle asset "/opt/conda/share/jupyter/lab/staging/vendors~pdfjsWorker.6fe3b09c29bfe510ab17.js": no such file

No bundles were parsed. Analyzer will show only original module sizes from stats file.

And the size it reports for vendors~main.3a8ea8f483a5a9147e64.js is "only" 43MB, while the js file in the build directory is 116MB.

As far as I can see there is not much duplication and plotly and beakerx are the biggest chunks....

[flixr]

Ah, got it: npx webpack-bundle-analyzer stats.json build now the "parsed size" reflects the size I actually see going over the wire.
No idea though why vendors~main.3a8ea8f483a5a9147e64.js is 115MB, but the "next level" it seems to contain node_modules is only 43MB

[juliusvonkohout]

@flixr @ian-r-rose the solution is to use --dev-build=False everytime you install something. the javascript went down from 55 to 8 Megabyte. The developers should make this default...

[flixr]

@juliusvonkohout as I already mentioned this didn't work for me:

I didn't have any luck with --dev-build=False: after 2h it ran into our CI timeout....

[flixr]

While a minimizing prod build still times out, I got down the size of the vendors~main.xxx.js by turning off inline-source-map as per #6804.
For anyone wanting to change this in you Dockerfile, add

sed -i 's/inline-source-map/source-map/g' /opt/conda/lib/python3.7/site-packages/jupyterlab/staging/webpack.config.js

before your jupyter labextension install foo or jupyter lab build.

[telamonian]

@flixr The jupyter lab build command was fixed up in #6907, but the changes haven't been included in a release yet. Once 1.1.0 is out, you should be able to get the build you need by running

jupyter lab build --minimize=False --dev-build=False

If you don't have any locally linked/installed labextensions, then you can also drop the --dev-build=False argument from the command.

[jasongrout]

Thanks @telamonian and @flixr for sharing your solutions!