Repository: dask/distributed

Issue:
Vertical size of Bokeh plots makes performance report illegible
**What happened**:
Vertical size of Bokeh plots (Task Stream, Worker Profile, etc.) is extremely large and plots are therefore not legible. Zooming browser out to 25% still doesn't get the whole plot in -- and at that point text becomes impossible to read. Using Brave on OSX. Chrome is slightly better but not much.

**What you expected to happen**:
Plots (both visuals and text) to be legible, ideally without having to zoom out.

**Minimal Complete Verifiable Example**:

```python
import dask
from dask.distributed import performance_report, Client

client = Client(n_workers=50)
df = dask.datasets.timeseries('2000', '2001')
df = df.persist()

with performance_report(filename="dask-report.html"):
    df.groupby('name').x.mean().compute()
```

**Anything else we need to know?**:

**Environment**:

- Dask version: 2021.07.1
- Python version: 3.8
- Operating System: OS 11.3.1
- Install method (conda, pip, source): conda

Screenshot attached
<img width="1426" alt="Screenshot 2021-07-28 at 17 36 51" src="https://user-images.githubusercontent.com/68642378/127363475-c970c48d-20a3-465a-9716-df6d7e359596.png">


Vertical size of Bokeh plots makes performance report illegible
**What happened**:
Vertical size of Bokeh plots (Task Stream, Worker Profile, etc.) is extremely large and plots are therefore not legible. Zooming browser out to 25% still doesn't get the whole plot in -- and at that point text becomes impossible to read. Using Brave on OSX. Chrome is slightly better but not much.

**What you expected to happen**:
Plots (both visuals and text) to be legible, ideally without having to zoom out.

**Minimal Complete Verifiable Example**:

```python
import dask
from dask.distributed import performance_report, Client

client = Client(n_workers=50)
df = dask.datasets.timeseries('2000', '2001')
df = df.persist()

with performance_report(filename="dask-report.html"):
    df.groupby('name').x.mean().compute()
```

**Anything else we need to know?**:

**Environment**:

- Dask version: 2021.07.1
- Python version: 3.8
- Operating System: OS 11.3.1
- Install method (conda, pip, source): conda

Screenshot attached
<img width="1426" alt="Screenshot 2021-07-28 at 17 36 51" src="https://user-images.githubusercontent.com/68642378/127363475-c970c48d-20a3-465a-9716-df6d7e359596.png">




Discussion:
Thanks for raising an issue @rrpelgrim! I updated your example to include a `Client`, hope that's okay. Unfortunately I'm not able to reproduce the issue you're seeing with the `main` branch of `distributed` and latest bokeh release (version `2.3.3`). Here's what I see when I look at the worker profile tab on my mac with Firefox:

<img width="1552" alt="Screen Shot 2021-07-28 at 12 02 29 PM" src="https://user-images.githubusercontent.com/11656932/127365404-bfd8fb18-f640-4504-88d9-33c4ef0264cd.png">

and with Chrome:

<img width="1552" alt="Screen Shot 2021-07-28 at 12 02 38 PM" src="https://user-images.githubusercontent.com/11656932/127365444-d0c43a6e-e16f-4153-84b4-7b41d86f4453.png">

For reference, what version of `bokeh` are you using? 

cc @ncclementi @jacobtomlinson for visibility 

EDIT: I also tried with `distributed=2021.07.1` and wasn't able to reproduce with that version either 
I've seen this a bit too, and found that the number of workers seems to be the issue. I also can't reproduce with the above example on `main` (using plain `Client()`):
![Screen Shot 2021-07-28 at 11 17 56 AM](https://user-images.githubusercontent.com/3309802/127367450-4cf9f809-1190-4a0c-aa26-c732cdb0b4f5.png)
but if I do `Client(n_workers=20)`, I get:
![Screen Shot 2021-07-28 at 11 17 59 AM](https://user-images.githubusercontent.com/3309802/127367490-9e8da882-4fd2-4a49-b3b3-be4c7375e8c1.png)

I can see that the `div` below `.bk-root` has a `height` set on the element, and in the bad case it's a very large number of pixels:
![Screen Shot 2021-07-28 at 11 21 02 AM](https://user-images.githubusercontent.com/3309802/127367867-6a2dcbd9-f03c-4a66-8861-9900cd406fb2.png)
![Screen Shot 2021-07-28 at 11 21 12 AM](https://user-images.githubusercontent.com/3309802/127367876-2963afa4-a86e-42b2-ab24-bc7f332b2823.png)

Not knowing anything about Bokeh, I'm not sure why the height is a fixed number of pixels instead of being responsive to the page size? But regardless, I'd think this top-level height should be a fixed value for every performance report, not somehow dependent on the data.
Update: for my example, upgrading to `bokeh==2.3.3` fixes this (thanks @ncclementi!). I also see that the height of that `div` is now a reasonable `1320px`.

Should we bump the minimum dependency for bokeh? @rrpelgrim you're still seeing this with 2.3.3? Just to be sure, can you run `import bokeh; bokeh.__version__` in Python in case anything odd is happening with `pip list` / `conda list`?
>  upgrading to bokeh==2.3.3 fixes this

Hmm that's interesting. I used `Client(n_workers=20)` and saw the vertical spacing issue using `bokeh=2.3.3` and the `main` branch of `distributed` (see below -- note the bottom of the file descriptors plot if cut off):

<img width="1552" alt="Screen Shot 2021-07-28 at 12 36 56 PM" src="https://user-images.githubusercontent.com/11656932/127370083-13db7630-471e-4807-bcc6-aaa493d0fea4.png">

When we add more workers, the "Scheduler Logs" tab becomes longer (i.e. we have more `Register worker ...` / `Starting worker ...` logs). It appears that the other tabs are stretched to match the size of the scheduler logs tab. For instance, if I temporarily remove the scheduler log tab with the following changes

```diff
diff --git a/distributed/scheduler.py b/distributed/scheduler.py
index 566f149f..7dfffb1d 100644
--- a/distributed/scheduler.py
+++ b/distributed/scheduler.py
@@ -7347,14 +7347,14 @@ class Scheduler(SchedulerState, ServerNode):
         )
         bandwidth_types = Panel(child=bandwidth_types.root, title="Bandwidth (Types)")
         system = Panel(child=sysmon.root, title="System")
-        logs = Panel(child=logs.root, title="Scheduler Logs")
+        # logs = Panel(child=logs.root, title="Scheduler Logs")

         tabs = Tabs(
             tabs=[
                 html,
                 task_stream,
                 system,
-                logs,
+                # logs,
                 compute,
                 workers,
                 scheduler,
```

then, even with `Client(n_workers=20)` all the other tabs fit nicely to my browser 

<img width="1552" alt="Screen Shot 2021-07-28 at 12 40 28 PM" src="https://user-images.githubusercontent.com/11656932/127370503-173e2584-243b-41c1-b1ce-a420f1b7ecf9.png">

@gjoseph92 could you try with, say, 100 workers on the current `main` to see if that increases the size of the scheduler logs enough for you to (possibly) see the vertical spacing issue? Or maybe try on a smaller screen
I can't reproduce either with the example above. Using firefox and:
`bokeh=2.3.3`  
`dask=2021.7.1`
`distributed=2021.7.0`

@gjoseph92 @rrpelgrim is running 2.3.3 (confirmed over slack). 


@jrbourbeau yup, using `Client(n_workers=100)` on main with bokeh 2.3.3 causes the problem.
![Screen Shot 2021-07-28 at 12 22 18 PM](https://user-images.githubusercontent.com/3309802/127375651-f73dfddc-0049-4864-95a5-13a272bfdccd.png)
And applying your patch fixes it.
![Screen Shot 2021-07-28 at 12 27 03 PM](https://user-images.githubusercontent.com/3309802/127376315-75cfd84b-6268-452b-9ede-6f24f99a4e08.png)

That explanation also makes sense, because a month ago is when I feel like I started seeing this: #4909.
I'd say that with the example above, I noticed that when reducing the window size, there is a moment that it stops scaling the plot and cuts it off, so you would need to scroll. 
![test](https://user-images.githubusercontent.com/7526622/127376695-f187a99e-8b64-496c-a851-1f463854fdd4.gif)

> yup, using Client(n_workers=100) on main with bokeh 2.3.3 causes the problem.

Thanks @gjoseph92 for confirming the scheduler log tab is the issue

> I'd say that with the example above, I noticed that when reducing the window size, there is a moment that it stops scaling the plot and cuts it off, so you would need to scroll.

Good observation. This is probably a good thing as, for very small screens, scrolling seems like a more legible alternative to having super tiny figures. I think what we want is to have the scheduler log tab follow a `stretch_both` sizing mode where it's doesn't result in other panels in the tabs being elongated. cc @charlesbluca for the scheduler logs connection and @bryevdv for visibility
I added in the `sizing_mode="stretch_both"` kwarg and while it does give the tab responsive sizing, it doesn't resolve the issue of the tab elongating to fit the full log output - I think what we would want here is a fixed max height to prevent the logs' containing `Div` from exceeding a specific height, though that would no longer be responsive.
cc @mattpap can you think go any reason offhand why a plot would extend well beyond the height of the viewport?
Note that this plot has always been a bit different than the others because
it is a combination of two charts, the rectangles on the top and the
timeseries on the bottom.

I've been thinking about arranging the profile information not by time, but
by TaskGroup, which might simplify this plot in the future.  (that's all
speculative though)

On Wed, Jul 28, 2021 at 10:48 PM Bryan Van de Ven ***@***.***>
wrote:

> cc @mattpap <https://github.com/mattpap> can you think go any reason
> offhand why a plot would extend well beyond the height of the viewport?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/dask/distributed/issues/5132#issuecomment-888778497>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AACKZTCNDTPDJ4TAW3445GDT2DFQDANCNFSM5BEXV4NQ>
> .
>

Thanks for the edit to my MVRE @jrbourbeau!
I tried using Firefox but issue persists for me. Interesting that you weren't able to reproduce. 
I'm viewing on my Macbook Pro 2020 13" screen -- wondering if it could be a laptop vs external screen issue?

For good measure, I can confirm that I'm running:
- bokeh: 2.3.3
- dask/distributed: 2021.07.1

FWIW, the Task Stream in the Dask performance report is slightly better than the one in the Coiled version (screencast below). But Worker and Scheduler profiles still barely legible. 

https://user-images.githubusercontent.com/68642378/127449805-8b377ccb-fe6e-473e-9c33-ed70e55f5aa6.mov
@rrpelgrim I still can't reproduce, same versions of bokeh, dask, and distributed. I'm on firefox and this is a recording of the whole screen of Macbook Pro 2021 13" (M1 chip though). Do you use pip or conda to install? 
I'm doing `client=Client()` as in the original example. 
![mac_screen](https://user-images.githubusercontent.com/7526622/127524051-1f66ba61-2202-4a14-8be8-6e97db71948b.gif)

There seem to be a couple of conversation threads happening at the same time. @rrpelgrim @ncclementi see https://github.com/dask/distributed/issues/5132#issuecomment-888497092 and https://github.com/dask/distributed/issues/5132#issuecomment-888527515 where we determined the issue is related to the size of the "Scheduler Logs" panel. You can increase the number of workers (e.g. `Client(n_workers=50)`) which will increase the size of the scheduler logs and result in the vertical size issue appearing 
Thanks for raising an issue @rrpelgrim! I updated your example to include a `Client`, hope that's okay. Unfortunately I'm not able to reproduce the issue you're seeing with the `main` branch of `distributed` and latest bokeh release (version `2.3.3`). Here's what I see when I look at the worker profile tab on my mac with Firefox:

<img width="1552" alt="Screen Shot 2021-07-28 at 12 02 29 PM" src="https://user-images.githubusercontent.com/11656932/127365404-bfd8fb18-f640-4504-88d9-33c4ef0264cd.png">

and with Chrome:

<img width="1552" alt="Screen Shot 2021-07-28 at 12 02 38 PM" src="https://user-images.githubusercontent.com/11656932/127365444-d0c43a6e-e16f-4153-84b4-7b41d86f4453.png">

For reference, what version of `bokeh` are you using? 

cc @ncclementi @jacobtomlinson for visibility 

EDIT: I also tried with `distributed=2021.07.1` and wasn't able to reproduce with that version either 
I've seen this a bit too, and found that the number of workers seems to be the issue. I also can't reproduce with the above example on `main` (using plain `Client()`):
![Screen Shot 2021-07-28 at 11 17 56 AM](https://user-images.githubusercontent.com/3309802/127367450-4cf9f809-1190-4a0c-aa26-c732cdb0b4f5.png)
but if I do `Client(n_workers=20)`, I get:
![Screen Shot 2021-07-28 at 11 17 59 AM](https://user-images.githubusercontent.com/3309802/127367490-9e8da882-4fd2-4a49-b3b3-be4c7375e8c1.png)

I can see that the `div` below `.bk-root` has a `height` set on the element, and in the bad case it's a very large number of pixels:
![Screen Shot 2021-07-28 at 11 21 02 AM](https://user-images.githubusercontent.com/3309802/127367867-6a2dcbd9-f03c-4a66-8861-9900cd406fb2.png)
![Screen Shot 2021-07-28 at 11 21 12 AM](https://user-images.githubusercontent.com/3309802/127367876-2963afa4-a86e-42b2-ab24-bc7f332b2823.png)

Not knowing anything about Bokeh, I'm not sure why the height is a fixed number of pixels instead of being responsive to the page size? But regardless, I'd think this top-level height should be a fixed value for every performance report, not somehow dependent on the data.
Update: for my example, upgrading to `bokeh==2.3.3` fixes this (thanks @ncclementi!). I also see that the height of that `div` is now a reasonable `1320px`.

Should we bump the minimum dependency for bokeh? @rrpelgrim you're still seeing this with 2.3.3? Just to be sure, can you run `import bokeh; bokeh.__version__` in Python in case anything odd is happening with `pip list` / `conda list`?
>  upgrading to bokeh==2.3.3 fixes this

Hmm that's interesting. I used `Client(n_workers=20)` and saw the vertical spacing issue using `bokeh=2.3.3` and the `main` branch of `distributed` (see below -- note the bottom of the file descriptors plot if cut off):

<img width="1552" alt="Screen Shot 2021-07-28 at 12 36 56 PM" src="https://user-images.githubusercontent.com/11656932/127370083-13db7630-471e-4807-bcc6-aaa493d0fea4.png">

When we add more workers, the "Scheduler Logs" tab becomes longer (i.e. we have more `Register worker ...` / `Starting worker ...` logs). It appears that the other tabs are stretched to match the size of the scheduler logs tab. For instance, if I temporarily remove the scheduler log tab with the following changes

```diff
diff --git a/distributed/scheduler.py b/distributed/scheduler.py
index 566f149f..7dfffb1d 100644
--- a/distributed/scheduler.py
+++ b/distributed/scheduler.py
@@ -7347,14 +7347,14 @@ class Scheduler(SchedulerState, ServerNode):
         )
         bandwidth_types = Panel(child=bandwidth_types.root, title="Bandwidth (Types)")
         system = Panel(child=sysmon.root, title="System")
-        logs = Panel(child=logs.root, title="Scheduler Logs")
+        # logs = Panel(child=logs.root, title="Scheduler Logs")

         tabs = Tabs(
             tabs=[
                 html,
                 task_stream,
                 system,
-                logs,
+                # logs,
                 compute,
                 workers,
                 scheduler,
```

then, even with `Client(n_workers=20)` all the other tabs fit nicely to my browser 

<img width="1552" alt="Screen Shot 2021-07-28 at 12 40 28 PM" src="https://user-images.githubusercontent.com/11656932/127370503-173e2584-243b-41c1-b1ce-a420f1b7ecf9.png">

@gjoseph92 could you try with, say, 100 workers on the current `main` to see if that increases the size of the scheduler logs enough for you to (possibly) see the vertical spacing issue? Or maybe try on a smaller screen
I can't reproduce either with the example above. Using firefox and:
`bokeh=2.3.3`  
`dask=2021.7.1`
`distributed=2021.7.0`

@gjoseph92 @rrpelgrim is running 2.3.3 (confirmed over slack). 


@jrbourbeau yup, using `Client(n_workers=100)` on main with bokeh 2.3.3 causes the problem.
![Screen Shot 2021-07-28 at 12 22 18 PM](https://user-images.githubusercontent.com/3309802/127375651-f73dfddc-0049-4864-95a5-13a272bfdccd.png)
And applying your patch fixes it.
![Screen Shot 2021-07-28 at 12 27 03 PM](https://user-images.githubusercontent.com/3309802/127376315-75cfd84b-6268-452b-9ede-6f24f99a4e08.png)

That explanation also makes sense, because a month ago is when I feel like I started seeing this: #4909.
I'd say that with the example above, I noticed that when reducing the window size, there is a moment that it stops scaling the plot and cuts it off, so you would need to scroll. 
![test](https://user-images.githubusercontent.com/7526622/127376695-f187a99e-8b64-496c-a851-1f463854fdd4.gif)

> yup, using Client(n_workers=100) on main with bokeh 2.3.3 causes the problem.

Thanks @gjoseph92 for confirming the scheduler log tab is the issue

> I'd say that with the example above, I noticed that when reducing the window size, there is a moment that it stops scaling the plot and cuts it off, so you would need to scroll.

Good observation. This is probably a good thing as, for very small screens, scrolling seems like a more legible alternative to having super tiny figures. I think what we want is to have the scheduler log tab follow a `stretch_both` sizing mode where it's doesn't result in other panels in the tabs being elongated. cc @charlesbluca for the scheduler logs connection and @bryevdv for visibility
I added in the `sizing_mode="stretch_both"` kwarg and while it does give the tab responsive sizing, it doesn't resolve the issue of the tab elongating to fit the full log output - I think what we would want here is a fixed max height to prevent the logs' containing `Div` from exceeding a specific height, though that would no longer be responsive.
cc @mattpap can you think go any reason offhand why a plot would extend well beyond the height of the viewport?
Note that this plot has always been a bit different than the others because
it is a combination of two charts, the rectangles on the top and the
timeseries on the bottom.

I've been thinking about arranging the profile information not by time, but
by TaskGroup, which might simplify this plot in the future.  (that's all
speculative though)

On Wed, Jul 28, 2021 at 10:48 PM Bryan Van de Ven ***@***.***>
wrote:

> cc @mattpap <https://github.com/mattpap> can you think go any reason
> offhand why a plot would extend well beyond the height of the viewport?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/dask/distributed/issues/5132#issuecomment-888778497>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AACKZTCNDTPDJ4TAW3445GDT2DFQDANCNFSM5BEXV4NQ>
> .
>

Thanks for the edit to my MVRE @jrbourbeau!
I tried using Firefox but issue persists for me. Interesting that you weren't able to reproduce. 
I'm viewing on my Macbook Pro 2020 13" screen -- wondering if it could be a laptop vs external screen issue?

For good measure, I can confirm that I'm running:
- bokeh: 2.3.3
- dask/distributed: 2021.07.1

FWIW, the Task Stream in the Dask performance report is slightly better than the one in the Coiled version (screencast below). But Worker and Scheduler profiles still barely legible. 

https://user-images.githubusercontent.com/68642378/127449805-8b377ccb-fe6e-473e-9c33-ed70e55f5aa6.mov
@rrpelgrim I still can't reproduce, same versions of bokeh, dask, and distributed. I'm on firefox and this is a recording of the whole screen of Macbook Pro 2021 13" (M1 chip though). Do you use pip or conda to install? 
I'm doing `client=Client()` as in the original example. 
![mac_screen](https://user-images.githubusercontent.com/7526622/127524051-1f66ba61-2202-4a14-8be8-6e97db71948b.gif)

There seem to be a couple of conversation threads happening at the same time. @rrpelgrim @ncclementi see https://github.com/dask/distributed/issues/5132#issuecomment-888497092 and https://github.com/dask/distributed/issues/5132#issuecomment-888527515 where we determined the issue is related to the size of the "Scheduler Logs" panel. You can increase the number of workers (e.g. `Client(n_workers=50)`) which will increase the size of the scheduler logs and result in the vertical size issue appearing 

Resolving patch:
diff --git a/distributed/dashboard/components/scheduler.py b/distributed/dashboard/components/scheduler.py
--- a/distributed/dashboard/components/scheduler.py
+++ b/distributed/dashboard/components/scheduler.py
@@ -2765,7 +2765,19 @@ def __init__(self, scheduler):
             "\n".join(line for level, line in scheduler.get_logs())
         )._repr_html_()
 
-        self.root = Div(text=logs)
+        self.root = Div(
+            text=logs,
+            style={
+                "width": "100%",
+                "height": "100%",
+                "max-width": "1920px",
+                "max-height": "1080px",
+                "padding": "12px",
+                "border": "1px solid lightgray",
+                "box-shadow": "inset 1px 0 8px 0 lightgray",
+                "overflow": "auto",
+            },
+        )
 
 
 def systemmonitor_doc(scheduler, extra, doc):
diff --git a/distributed/scheduler.py b/distributed/scheduler.py
--- a/distributed/scheduler.py
+++ b/distributed/scheduler.py
@@ -7346,7 +7346,19 @@ def profile_to_figure(state):
             dask_version=dask.__version__,
             distributed_version=distributed.__version__,
         )
-        html = Div(text=html)
+        html = Div(
+            text=html,
+            style={
+                "width": "100%",
+                "height": "100%",
+                "max-width": "1920px",
+                "max-height": "1080px",
+                "padding": "12px",
+                "border": "1px solid lightgray",
+                "box-shadow": "inset 1px 0 8px 0 lightgray",
+                "overflow": "auto",
+            },
+        )
 
         html = Panel(child=html, title="Summary")
         compute = Panel(child=compute, title="Worker Profile (compute)")


Test patch: