Skip to content
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

Target performance for use in peerpad #7

Closed
1 of 4 tasks
fritzy opened this issue May 8, 2018 · 1 comment
Closed
1 of 4 tasks

Target performance for use in peerpad #7

fritzy opened this issue May 8, 2018 · 1 comment
Assignees

Comments

@fritzy
Copy link
Contributor

fritzy commented May 8, 2018

Since we want to use peer-crdt for peerpad, we need to create a performance test and determine a performance target.

  • 1,000 dag operation test with several branches and simulated network latency
    • several branches
    • network latency
    • use the register type and collide occasionally on set
  • determine how many operations per second a typical peerpad session creates
    • 3 people typing at once
    • y.js + richtext type
    • Can peer-crdt keep up with a similar workload?
  • develop textarea demo with peer-crdt
  • develop richtext type for for peer-crdt

At this point, we can start implementing more optimizations if needed (faster dag merging, rollups to remove the need to fetch serially, etc).

@legastero
Copy link
Contributor

For the DAG operations test, I had three peers in the network, where each peer was chosen randomly to apply one of N operations to a lww-register CRDT. This was a stress test, where all of the operations were performed rapidly, to see how long it would then take for the peers to converge.

When N was 500, it took the three peers 17 minutes to converge.

When N was 1000, the test ran for over 5 hours and then crashed from lack of RAM.

Profiling showed a performance bottleneck in the _isChildOf() log method, and an improved version of the method has been patched in #8

Using the patched version, 500 changes took ~30 seconds before convergence, and 1000 changes took 70-80 seconds.

This is remarkably faster than before, but likely needs more optimization since this was using the virtual network used by the current tests and not including real-world network latency costs.

@fritzy fritzy closed this as completed Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants