Server close faster

[fjetter]

This supersedes #6414
closes #6413
xref closes #6365
Follow up of #4805 where I dealt with other ongoing handlers but didn't special case terminate / close

This offers a few benefits over #6414

• Removes any special treatments of any op / handler-names by referencing the currently running asyncio task.
• It removes polling. Subjectively this makes the code a bit better readable and intentions are clearer. This also prepares us to eventually deal with exceptions. I haven't implemented any exception handling this this would require much more thorough testing to define the behavior of the server after an exception was caught (e.g. ensure it is still closing properly)

cc @mrocklin @hendrikmakait

[github-actions]

Unit Test Results

       15 files  ±  0         15 suites  ±0   6h 41m 50s ⏱️ - 3m 45s
  2 808 tests +  2    2 725 ✔️ +  1    79 💤  - 1  4 ❌ +2 
20 818 runs  +15  19 886 ✔️ +15  928 💤  - 2  4 ❌ +2 

For more details on these failures, see this check.

Results for commit 2551272. ± Comparison against base commit 9bb999d.

♻️ This comment has been updated with latest results.

[fjetter]

This is because the scheduler.close does no longer use an explicit comm to close the remote worker.
This behavior was introduced in #6363

[mrocklin]

Seems to be fast on subsequent close calls

In [1]: from dask.distributed import LocalCluster

In [2]: %%time
   ...: with LocalCluster(processes=False, n_workers=3):
   ...:     pass
   ...: 
CPU times: user 853 ms, sys: 120 ms, total: 972 ms
Wall time: 2.29 s

In [3]: %%time
   ...: with LocalCluster(processes=False, n_workers=3):
   ...:     pass
   ...: 
CPU times: user 106 ms, sys: 20.3 ms, total: 127 ms
Wall time: 132 ms

👍

[fjetter]

Im surprised to see the first one taking that long. In my tests, the first call took about 150ms and the second one 30ms

[fjetter]

timing for me

Python 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:42:03) [Clang 12.0.1 ]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.2.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from dask.distributed import LocalCluster

In [2]: %%time
   ...: with LocalCluster(processes=False, n_workers=0):
   ...:     pass
   ...:
CPU times: user 237 ms, sys: 52.1 ms, total: 289 ms
Wall time: 358 ms

In [3]: %%time
   ...: with LocalCluster(processes=False, n_workers=0):
   ...:     pass
   ...:
CPU times: user 20.5 ms, sys: 2.52 ms, total: 23 ms
Wall time: 22.9 ms

I just realize in #6415 (comment) there are three workers. Maybe the first call is slow/fast enough to actually get a worker process up such that the closing takes longer

[mrocklin]

Woot

…

On Mon, May 23, 2022 at 12:55 PM Florian Jetter ***@***.***> wrote: timing for me Python 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:42:03) [Clang 12.0.1 ]Type 'copyright', 'credits' or 'license' for more informationIPython 8.2.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: from dask.distributed import LocalCluster In [2]: %%time ...: with LocalCluster(processes=False, n_workers=0): ...: pass ...:CPU times: user 237 ms, sys: 52.1 ms, total: 289 msWall time: 358 ms In [3]: %%time ...: with LocalCluster(processes=False, n_workers=0): ...: pass ...:CPU times: user 20.5 ms, sys: 2.52 ms, total: 23 msWall time: 22.9 ms — Reply to this email directly, view it on GitHub <#6415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACKZTEVIEVPN7EQOHV4HTLVLPA7PANCNFSM5WVGMKCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>