-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process-wide channel cache for gRPC+aio #120
Conversation
e7ca5e9
to
e9e47d1
Compare
36efba0
to
f6b484e
Compare
hivemind/client/allreduce.py
Outdated
@@ -150,9 +150,7 @@ async def accumulate(self, source: Endpoint, part: torch.Tensor) -> torch.Tensor | |||
return await self.averaged_part | |||
|
|||
def _get(self, peer: Endpoint) -> averaging_pb2_grpc.DecentralizedAveragingStub: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe _get is slightly overloaded here, how about _get_peer_stub?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its mostly a convention with DHTProtocol._get, should we rename both?
from __future__ import annotations | ||
import os | ||
import threading | ||
from typing import NamedTuple, Sequence, Tuple, Optional, Union, Any, Dict, TypeVar, Type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're using from __future__ import annotations
, do we need to import tuple and dict from typing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree, but i would request to keep it as is AND write a todo for #98 , ok?
MAXIMUM_CHANNELS = os.environ.get("GRPC_PYTHON_MANAGED_CHANNEL_MAXIMUM", 4096) | ||
EVICTION_PERIOD_SECONDS = os.environ.get("GRPC_PYTHON_MANAGED_CHANNEL_EVICTION_SECONDS", 10 * 60) | ||
logger.debug(f"Eviction period = {EVICTION_PERIOD_SECONDS}s, max channels = {MAXIMUM_CHANNELS}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These constants should be module-level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(fixed, thanks!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
upd - it complicates testing, added to #98
hivemind/utils/grpc.py
Outdated
_eviction_thread: threading.Thread | ||
_nearest_expiration_time: DHTExpiration | ||
_is_active: bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are instance attributes and are declared during init
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(fixed)
Co-authored-by: Max Ryabinin <[email protected]>
Co-authored-by: Max Ryabinin <[email protected]>
… into dht_update_nov
process-wide channel caching
Currently, each time we query a remote peer with gRPC, we have to create a new channel.
In contrast, gRPC best practices recommend reusing channels for multiple rpc calls
hivemind/client/expert.py introduced channel caching, but it had a side-effect of keeping channels open forever
In this PR we implement a process-wide ChannelCache object that keeps track of open channels. The code is largely inspired by https://github.com/grpc/grpc/blob/master/src/python/grpcio/grpc/_simple_stubs.py , but with the added support for grpc.aio channels.