Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • hive hive
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 170
    • Issues 170
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 29
    • Merge requests 29
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • hivehive
  • hivehive
  • Issues
  • #246
Closed
Open
Issue created Mar 21, 2022 by Dan Notestein@danOwner

Test p2p code changes inside mirror testnet

Currently the changes required to speedup p2p performance have only been tested on the mainnet. Since most of the mainnet nodes are not running the faster new code, there could be a problem that will only be exposed when all the nodes in a network are running with the new code. To ensure this is not the case, we need to run a testnet that only has "new p2p" nodes.

Some scenarios to verify:

  • All nodes on mirror testnet, running new code, in live mode
  • Introduce a new node to above network that needs to sync from scratch (time the performance as well)
  • Setup one or more of the nodes as API nodes and load them with API traffic
  • Sync a node with sql_serializer (time the performance as well)
  • Test nodes operating under live mode, temporarily fork the network (i.e. create a situation where two or more sets of nodes have lost connectivity to the other sets), and ensure the "best fork" wins
  • Introduce a syncing node to the above scenario and ensure it successfully chooses the correct fork

Other metrics of interest in the above scenarios: cpu% percentage consumed by both p2p and write_queue threads

Edited May 15, 2022 by Dan Notestein
Assignee
Assign to
Time tracking