Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Stage 3 - Single routing table (rather than one per Sybil) #19

Open
alanshaw opened this issue Mar 9, 2020 · 0 comments
Open

Stage 3 - Single routing table (rather than one per Sybil) #19

alanshaw opened this issue Mar 9, 2020 · 0 comments
Labels

Comments

@alanshaw
Copy link
Member

alanshaw commented Mar 9, 2020

Effort Needed: Low (1 week of developing + testing + deployment)
Prerequisite(s): Stage 1 & Stage 2

Design notes & tasks

  • This is a perf optimization. Rather than having N routing tables, where N is the number of sybils, sharing a connection pool (and therefore blocking each other), we want to only have one of the PeerIds doing the routing, while the others are just in the routing tables of other peers
  • Use delegated routing for each of the sybils to use the router sybil to fetch the records

Testing mechanics & evaluation plan

  • Deploy the nodes. Measure the memory, cpu and bandwidth profiles. There should be a drop comparing to previous version.

Success criteria

  • The sybils do not thrash each other when sharing the connection pool
  • The sybils become less noisy (as only one node will have a large routing table, rather than N nodes having many small routing tables that need to be constantly updated)
@alanshaw alanshaw pinned this issue Mar 9, 2020
@alanshaw alanshaw added the Epic label Mar 9, 2020
@lidel lidel unpinned this issue Jun 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant