From 879e7b147fe82f1dfec00a3a0f4618dadc4f85f3 Mon Sep 17 00:00:00 2001 From: Alexander Kozlovsky Date: Mon, 24 Oct 2022 04:37:17 +0200 Subject: [PATCH] Add a comment to the `max_query_peers` option --- .../metadata_store/remote_query_community/settings.py | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/tribler/core/components/metadata_store/remote_query_community/settings.py b/src/tribler/core/components/metadata_store/remote_query_community/settings.py index 66ee1737047..9fcd21bdbf5 100644 --- a/src/tribler/core/components/metadata_store/remote_query_community/settings.py +++ b/src/tribler/core/components/metadata_store/remote_query_community/settings.py @@ -5,7 +5,16 @@ class RemoteQueryCommunitySettings(TriblerConfigSection): minimal_blob_size: int = 200 maximum_payload_size: int = 1300 max_entries: int = maximum_payload_size // minimal_blob_size + + # The next option is currently used by GigaChannelCommunity only. We probably should move it to the + # GigaChannelCommunity settings or to a dedicated search-related section. The value of the option is corresponding + # with the TARGET_PEERS_NUMBER of src/tribler/core/components/gigachannel/community/sync_strategy.py, that is, to + # the number of peers that GigaChannelCommunity will have after a long run (initially, the number of peers in + # GigaChannelCommunity can rise up to several hundred due to DiscoveryBooster). The number of parallel remote + # requests should be not too small (to have various results from remote peers) and not too big (to avoid flooding + # the network with exceedingly high number of queries). TARGET_PEERS_NUMBER looks like a good middle ground here. max_query_peers: int = 20 + max_response_size: int = 100 # Max number of entries returned by SQL query max_channel_query_back: int = 4 # Max number of entries to query back on receiving an unknown channel push_updates_back_enabled = True