Skip to content

Align snapshot confs to prevent excessive DB patching#1279

Merged
hackerwins merged 1 commit into
mainfrom
presence-only
May 22, 2025
Merged

Align snapshot confs to prevent excessive DB patching#1279
hackerwins merged 1 commit into
mainfrom
presence-only

Conversation

@hackerwins

@hackerwins hackerwins commented May 22, 2025 •
edited
Loading

Copy link
Copy Markdown
Member

What this PR does / why we need it:

Previously, snapshots were stored every 3000 changes(SnapshotInterval), and sent to new clients if pulled changes exceeded 500(SnapshotThreshold) in PushPullChanges API. This mismatch led to a case where, with around 500 concurrent clients, a newly connected client might trigger the server to fetch around 3000 changes from the database.

This change sets both the snapshot interval and change threshold to 500, ensuring the server never needs to patch more than 500 changes at once.

Before:

  █ THRESHOLDS 

    control_doc_latency
    ✓ 'p(95)<500' p(95)=0

    http_req_duration
    ✓ 'p(95)<10000' p(95)=4.07s

    transaction_success_rate
    ✓ 'rate>0.99' rate=100.00%

After:

  █ THRESHOLDS 

    control_doc_latency
    ✓ 'p(95)<500' p(95)=0

    http_req_duration
    ✓ 'p(95)<10000' p(95)=2.11s

    transaction_success_rate
    ✓ 'rate>0.99' rate=100.00%

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Additional documentation:

Checklist:

  • Added relevant tests or not required
  • Addressed and resolved all CodeRabbit review comments
  • Didn't break anything

Summary by CodeRabbit

  • Refactor
    • Renamed methods related to updating version vectors for improved clarity across the backend.
    • Simplified snapshot storage logic and removed parameters related to garbage collection.
  • Chores
    • Updated default snapshot threshold and interval settings to lower values for more frequent snapshots.
    • Removed the snapshot purging option from the sample configuration file.

@coderabbitai

coderabbitai Bot commented May 22, 2025 •
edited
Loading

Copy link
Copy Markdown

Walkthrough

This change renames the method UpdateAndFindMinVersionVector to UpdateMinVersionVector across the database interface and its implementations, updates related comments, and refactors all usages accordingly. Additionally, it removes the minimum version vector parameter from snapshot storage logic, simplifies snapshot-related code, and updates default snapshot configuration values.

Changes

File(s) Change Summary
server/backend/database/database.go
server/backend/database/memory/database.go
server/backend/database/mongo/client.go		 Renamed the method UpdateAndFindMinVersionVector to UpdateMinVersionVector in the Database interface and its memory and MongoDB implementations. Updated associated comments to reflect the new name and clarified the method's purpose. No changes to logic or parameters except for the method name.
server/packs/packs.go Updated the PushPull operation to use UpdateMinVersionVector instead of the old method. Removed handling of the returned minimum version vector and eliminated passing it to snapshot storage.
server/packs/snapshots.go Removed the minSyncedVersionVector parameter from storeSnapshot and all related garbage collection logic. Renamed variables for clarity and simplified snapshot info retrieval.
server/config.go Changed the default values for DefaultSnapshotThreshold and DefaultSnapshotInterval from 1000/3000 to 500/500.
server/config.sample.yml Reduced SnapshotThreshold and SnapshotInterval values from 1000/3000 to 500/500, and removed the SnapshotWithPurgingChanges setting from the sample configuration.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Packs
    participant Database
    participant Snapshots

    Client->>Packs: PushPull request
    Packs->>Database: UpdateMinVersionVector(ctx, clientInfo, docRefKey, versionVector)
    Database-->>Packs: (returns minVersionVector)
    Packs->>Snapshots: storeSnapshot(ctx, backend, docInfo)
    Snapshots->>Database: SaveSnapshot(ctx, snapshotInfo)
    Database-->>Snapshots: (ack)
    Snapshots-->>Packs: (ack)
    Packs-->>Client: PushPull response
Loading

Possibly related PRs

  • yorkie-team/yorkie#1170: Refactors version vector Min/Max operations and removes unused FindMinVersionVector, directly related to the method renaming and usage changes in this PR.
  • yorkie-team/yorkie#1047: Introduces the VersionVector feature and database schema changes, providing the foundational logic for the methods renamed and updated in this PR.
  • yorkie-team/yorkie#1153: Adds a helper for finding the minimum version vector and refactors related logic, closely tied to the method and computation updated in this PR.

Note

⚡️ AI Code Reviews for VS Code, Cursor, Windsurf

CodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback.
Learn more here.

Note

⚡️ Faster reviews with caching

CodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 30th. To opt out, configure Review - Disable Cache at either the organization or repository level. If you prefer to disable all data retention across your organization, simply turn off the Data Retention setting under your Organization Settings.
Enjoy the performance boost—your workflow just got faster.

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 686b3cb and 77e2512.

📒 Files selected for processing (7)
  • server/backend/database/database.go (1 hunks)
  • server/backend/database/memory/database.go (1 hunks)
  • server/backend/database/mongo/client.go (1 hunks)
  • server/config.go (1 hunks)
  • server/config.sample.yml (1 hunks)
  • server/packs/packs.go (1 hunks)
  • server/packs/snapshots.go (2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: bench
  • GitHub Check: build
🔇 Additional comments (14)
server/config.sample.yml (2)

54-54: Configuration value update for SnapshotThreshold

The snapshot threshold has been reduced from 1000 to 500, which means snapshots will be created more frequently when the number of changes exceeds this lower threshold.

57-57: Configuration value update for SnapshotInterval

The snapshot interval has been significantly reduced from 3000 to 500, resulting in more frequent snapshot creation. This aligns with the reduced threshold value above, indicating a shift toward more frequent, smaller snapshots.

server/config.go (1)

70-71: Default snapshot configuration values updated

The default values for DefaultSnapshotThreshold and DefaultSnapshotInterval have been reduced to 500, consistent with the changes in the sample configuration file. This adjustment will lead to more frequent snapshot creation.

server/backend/database/database.go (1)

292-293: Method renamed for clarity of purpose

The method has been renamed from UpdateAndFindMinVersionVector to UpdateMinVersionVector and its comment updated to focus on its primary responsibility of updating the version vector, rather than emphasizing the return value.

server/packs/packs.go (2)

138-139: Updated method call to reflect API change

Updated comment and method call to use the renamed UpdateMinVersionVector method, aligning with the interface change in the database package.

221-228: Simplified snapshot storage call

The call to storeSnapshot has been updated to remove the minVersionVector parameter, reflecting the simplified snapshot storage process that no longer uses this value for garbage collection.

server/backend/database/mongo/client.go (1)

1342-1344: Method rename improves clarity and aligns with actual behavior.

The method has been renamed from UpdateAndFindMinVersionVector to UpdateMinVersionVector, which better reflects its actual responsibility. While it still returns the minimum version vector, the new name puts the focus on the primary action (updating) rather than suggesting two equally important operations.

server/backend/database/memory/database.go (1)

1446-1448: Method rename maintains consistency across database implementations.

The method has been renamed from UpdateAndFindMinVersionVector to UpdateMinVersionVector, matching the same change in the MongoDB implementation. This maintains a consistent interface across different database backends.

server/packs/snapshots.go (6)

29-34: Simplified function signature by removing the unused minSyncedVersionVector parameter.

The function signature has been simplified by removing the minSyncedVersionVector parameter that was previously used for garbage collection. This makes the function more focused on its primary responsibility of storing snapshots.

37-43: Improved variable naming and code formatting for better readability.

The variable was renamed from snapshotMetadata to snapshotInfo, which better describes its purpose. The code formatting was also improved for better readability.

46-51: Simplified conditional checks and removed references to the previous variable name.

The conditional checks were updated to use the new variable name snapshotInfo instead of snapshotMetadata. The first check was also simplified to directly compare server sequences.

64-70: Simplified snapshot info retrieval logic.

The logic for fetching the full snapshot info by reference key was simplified by introducing a clear conditional check on the snapshot ID before making the additional database call.

109-109: Removed garbage collection logic for a more focused snapshot storage.

The garbage collection logic was removed from the end of the function, which decouples snapshot storage from garbage collection, resulting in a more focused function that adheres to the single responsibility principle.

91-93:

Details

✅ Verification successful

Verify if the SnapshotDisableGC flag is still needed.

With the removal of the garbage collection from the storeSnapshot function, it's worth checking if the SnapshotDisableGC flag still serves a purpose in the ApplyChangePack call, or if this should be revisited as well.

🏁 Script executed:

#!/bin/bash
# Check where the SnapshotDisableGC flag is used and if it's still relevant
echo "Searching for SnapshotDisableGC usage in the codebase:"
grep -r "SnapshotDisableGC" --include="*.go" .

echo -e "\nChecking if ApplyChangePack actually uses the flag:"
grep -A 20 "func.*ApplyChangePack" --include="*.go" .

Length of output: 1114

🏁 Script executed:

#!/bin/bash
# Locate all usages and the definition of ApplyChangePack
echo "=== All occurrences of ApplyChangePack ==="
grep -R -n "ApplyChangePack(" --include="*.go" .

echo -e "\n=== Definition of ApplyChangePack ==="
grep -R -n "func.*ApplyChangePack" --include="*.go" .

Length of output: 1855

#!/bin/bash
# Inspect the implementation of InternalDocument.ApplyChangePack to see how the disableGC flag is used
echo "=== InternalDocument.ApplyChangePack implementation ==="
grep -R -n "func (d \\*InternalDocument) ApplyChangePack" -A 200 --include="internal_document.go" pkg/document/internal_document.go

🏁 Script executed:

#!/bin/bash
# Extract the implementation of InternalDocument.ApplyChangePack to inspect disableGC usage
grep -R -n 'func (d \*InternalDocument) ApplyChangePack' -A 200 pkg/document/internal_document.go

Length of output: 7075

SnapshotDisableGC flag remains necessary

The disableGC parameter in InternalDocument.ApplyChangePack (pkg/document/internal_document.go:189–193) still governs whether d.GarbageCollect is invoked when applying a change pack. Although GC was removed from storeSnapshot, it’s now centralized here—so the SnapshotDisableGC flag continues to serve its intended purpose. No changes required.

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codecov

codecov Bot commented May 22, 2025 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

Attention: Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.

Project coverage is 37.00%. Comparing base (686b3cb) to head (77e2512).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
server/packs/snapshots.go 0.00% 9 Missing ⚠️
server/packs/packs.go 0.00% 1 Missing ⚠️
Additional details and impacted files 
@@           Coverage Diff           @@
##             main    #1279   +/-   ##
=======================================
  Coverage   36.99%   37.00%           
=======================================
  Files         180      180           
  Lines       28424    28417    -7     
=======================================
  Hits        10516    10516           
+ Misses      17020    17013    -7     
  Partials      888      888

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

hackerwins-yorkie
hackerwins-yorkie reviewed May 22, 2025
View reviewed changes

@hackerwins-yorkie hackerwins-yorkie left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Go Benchmark Analysis 📊

This is a comparison result between the previous(686b3cb) and the current commit(cc04393).

Significant Changes (≥20% difference)

Benchmark suite Previous Current Change
BenchmarkVersionVector/clients_1000/ (7_pushpull_after_detach(ms)) 5.00 ms 6.00 ms 🔴 +20.00%

Key Observations 🔍

  • The benchmark suite BenchmarkVersionVector/clients_1000/ (7_pushpull_after_detach(ms) shows a significant increase of +20.00% in the current timing compared to the previous timing.
  • In general, the benchmark data demonstrates a mix of improvements and minor fluctuations across different test suites, with no consistent negative trends observed.
  • Several benchmarks show minor improvements ranging from -3.37% to -0.25%, indicating some optimization in performance.
  • The BenchmarkLocker and BenchmarkLockerParallel suites show minor increases of +4.41% and +0.15% respectively, suggesting slightly extended processing times in these scenarios.
  • The BenchmarkTree suite portrays consistent improvements in the range of -4.75% to -3.25% across various test scenarios involving different numbers of vertices.

Overall, the benchmark data showcases a balance of fluctuations with some areas demonstrating optimization while others experience slight performance degradation.

Clock Analysis

Lamport vs VersionVector

BenchmarkVersionVector Test

Lamport (v0.5.2)
Metric 10 clients 100 clients 1000 clients
Total Operation Time 84.96 ms 793.94 ms 34.79 s
Memory Allocations 35.11 MB 219.92 MB 4.91 GB
Number of Allocations (allocs/op) 69,271 1,246,728 81,485,288
ChangePack Size 138.0 B 137.0 B 141.0 B
Snapshot Size 379.0 B 3.08 KB 30.08 KB
Push-Pull Time 2.0 ms 1.5 ms 4.0 ms
Attach Time 4.5 ms 11.0 ms 31.0 ms
ChangePack After Detach 138.0 B 140.0 B 141.0 B
Snapshot After Detach 136.0 B 137.0 B 139.0 B
Push-Pull After Detach 2.5 ms 5.0 ms 9.5 ms
Version Vector (current)
Metric 10 clients 100 clients 1000 clients
Total Operation Time 129.48 ms 1.07 s 14.94 s
Memory Allocations 6.82 MB 75.74 MB 2.02 GB
Number of Allocations (allocs/op) 58,158 750,268 36,350,605
ChangePack Size [N/A] [N/A] [N/A]
Snapshot Size [N/A] [N/A] [N/A]
Push-Pull Time [N/A] [N/A] [N/A]
Attach Time [N/A] [N/A] [N/A]
ChangePack After Detach [N/A] [N/A] [N/A]
Snapshot After Detach [N/A] [N/A] [N/A]
Push-Pull After Detach [N/A] [N/A] [N/A]

BenchmarkSyncConcurrency Test

Metric Clients Lamport (v0.5.2) Version Vector (current)
Total Operation Time 1-100-10-10 7.48 s 15.26 s
100-100-10-10 9.62 s 16.52 s
300_100-10-10 14.77 s 18.88 s
Memory Allocations 1-100-10-10 1.15 GB 7.63 GB
100-100-10-10 1.45 GB 7.76 GB
300_100-10-10 2.19 GB 8.06 GB
Number of Allocations (allocs/op) 1-100-10-10 17,107,766 157,834,636
100-100-10-10 20,084,480 159,976,512
300_100-10-10 30,359,215 165,654,770

Summary

  • The Version Vector clock system shows improvements in total operation time and memory allocations compared to Lamport for different numbers of clients. However, the Version Vector clock system seems to have more variability in performance across different metrics.
  • In terms of concurrency, the Version Vector clock system generally exhibits longer total operation times and higher memory allocations compared to Lamport for varying concurrency settings. However, the number of allocations per operation is lower for the Version Vector system, indicating potentially more efficient memory usage.

Detailed Test Results

BenchmarkDeletionConcurrency
Benchmark suite Previous Current Change
concurrent_text_delete_range_100/ (ns/op) 866.69 ms 855.51 ms 🟢 -1.29%
concurrent_text_delete_range_100/ (B/op) 61.55 MB 58.01 MB 🟢 -5.75%
concurrent_text_delete_range_100/ (allocs/op) 749,730 allocs 749,476 allocs 🟢 -0.03%
concurrent_text_delete_range_1000/ (ns/op) 7.15 s 7.16 s 🔴 +0.17%
concurrent_text_delete_range_1000/ (B/op) 381.53 MB 375.80 MB 🟢 -1.50%
concurrent_text_delete_range_1000/ (allocs/op) 7,256,255 allocs 7,254,864 allocs 🟢 -0.02%
concurrent_tree_delete_range_100/ (ns/op) 874.40 ms 868.39 ms 🟢 -0.69%
concurrent_tree_delete_range_100/ (B/op) 67.75 MB 66.61 MB 🟢 -1.68%
concurrent_tree_delete_range_100/ (allocs/op) 787,053 allocs 786,954 allocs 🟢 -0.01%
concurrent_tree_delete_range_1000/ (ns/op) 7.84 s 7.76 s 🟢 -1.00%
concurrent_tree_delete_range_1000/ (B/op) 909.68 MB 907.30 MB 🟢 -0.26%
concurrent_tree_delete_range_1000/ (allocs/op) 7,565,728 allocs 7,565,118 allocs ⚪ 0%
concurrent_text_edit_delete_all_100/ (ns/op) 748.58 ms 748.26 ms 🟢 -0.04%
concurrent_text_edit_delete_all_100/ (B/op) 54.88 MB 53.18 MB 🟢 -3.10%
concurrent_text_edit_delete_all_100/ (allocs/op) 632,850 allocs 632,789 allocs ⚪ 0%
concurrent_text_edit_delete_all_1000/ (ns/op) 5.96 s 5.93 s 🟢 -0.61%
concurrent_text_edit_delete_all_1000/ (B/op) 329.47 MB 320.84 MB 🟢 -2.62%
concurrent_text_edit_delete_all_1000/ (allocs/op) 5,918,277 allocs 5,917,418 allocs 🟢 -0.01%
concurrent_tree_edit_delete_all_100/ (ns/op) 771.78 ms 774.24 ms 🔴 +0.32%
concurrent_tree_edit_delete_all_100/ (B/op) 85.67 MB 83.38 MB 🟢 -2.67%
concurrent_tree_edit_delete_all_100/ (allocs/op) 862,887 allocs 862,813 allocs ⚪ 0%
concurrent_tree_edit_delete_all_1000/ (ns/op) 6.52 s 6.49 s 🟢 -0.57%
concurrent_tree_edit_delete_all_1000/ (B/op) 729.66 MB 732.14 MB 🔴 +0.34%
concurrent_tree_edit_delete_all_1000/ (allocs/op) 6,325,378 allocs 6,325,627 allocs ⚪ 0%
BenchmarkDocument
Benchmark suite Previous Current Change
constructor_test/ (ns/op) 1465.00 ns 1451.00 ns 🟢 -0.96%
constructor_test/ (B/op) 1.45 KB 1.45 KB ⚪ 0%
constructor_test/ (allocs/op) 25 allocs 25 allocs ⚪ 0%
status_test/ (ns/op) 1071.00 ns 1068.00 ns 🟢 -0.28%
status_test/ (B/op) 1.42 KB 1.42 KB ⚪ 0%
status_test/ (allocs/op) 23 allocs 23 allocs ⚪ 0%
equals_test/ (ns/op) 8012.00 ns 8071.00 ns 🔴 +0.74%
equals_test/ (B/op) 7.89 KB 7.89 KB ⚪ 0%
equals_test/ (allocs/op) 135 allocs 135 allocs ⚪ 0%
nested_update_test/ (ns/op) 17596.00 ns 17486.00 ns 🟢 -0.63%
nested_update_test/ (B/op) 12.71 KB 12.71 KB ⚪ 0%
nested_update_test/ (allocs/op) 267 allocs 267 allocs ⚪ 0%
delete_test/ (ns/op) 23517.00 ns 24031.00 ns 🔴 +2.19%
delete_test/ (B/op) 16.30 KB 16.30 KB ⚪ 0%
delete_test/ (allocs/op) 350 allocs 350 allocs ⚪ 0%
object_test/ (ns/op) 8957.00 ns 8967.00 ns 🔴 +0.11%
object_test/ (B/op) 7.27 KB 7.27 KB ⚪ 0%
object_test/ (allocs/op) 123 allocs 123 allocs ⚪ 0%
array_test/ (ns/op) 29474.00 ns 29396.00 ns 🟢 -0.26%
array_test/ (B/op) 12.55 KB 12.55 KB ⚪ 0%
array_test/ (allocs/op) 282 allocs 282 allocs ⚪ 0%
text_test/ (ns/op) 33061.00 ns 32933.00 ns 🟢 -0.39%
text_test/ (B/op) 15.41 KB 15.41 KB ⚪ 0%
text_test/ (allocs/op) 505 allocs 505 allocs ⚪ 0%
text_composition_test/ (ns/op) 31037.00 ns 31114.00 ns 🔴 +0.25%
text_composition_test/ (B/op) 16.85 KB 16.85 KB ⚪ 0%
text_composition_test/ (allocs/op) 489 allocs 489 allocs ⚪ 0%
rich_text_test/ (ns/op) 86243.00 ns 86784.00 ns 🔴 +0.63%
rich_text_test/ (B/op) 38.91 KB 38.91 KB ⚪ 0%
rich_text_test/ (allocs/op) 1,185 allocs 1,185 allocs ⚪ 0%
counter_test/ (ns/op) 18516.00 ns 18639.00 ns 🔴 +0.66%
counter_test/ (B/op) 12.37 KB 12.37 KB ⚪ 0%
counter_test/ (allocs/op) 260 allocs 260 allocs ⚪ 0%
text_edit_gc_100/ (ns/op) 1.42 ms 1.41 ms 🟢 -0.27%
text_edit_gc_100/ (B/op) 810.04 KB 809.96 KB 🟢 -0.01%
text_edit_gc_100/ (allocs/op) 16,787 allocs 16,787 allocs ⚪ 0%
text_edit_gc_1000/ (ns/op) 55.29 ms 56.48 ms 🔴 +2.14%
text_edit_gc_1000/ (B/op) 46.29 MB 46.29 MB ⚪ 0%
text_edit_gc_1000/ (allocs/op) 180,596 allocs 180,607 allocs ⚪ 0%
text_split_gc_100/ (ns/op) 2.12 ms 2.13 ms 🔴 +0.15%
text_split_gc_100/ (B/op) 1.53 MB 1.53 MB ⚪ 0%
text_split_gc_100/ (allocs/op) 15,555 allocs 15,556 allocs ⚪ 0%
text_split_gc_1000/ (ns/op) 133.17 ms 132.27 ms 🟢 -0.67%
text_split_gc_1000/ (B/op) 137.30 MB 137.30 MB ⚪ 0%
text_split_gc_1000/ (allocs/op) 181,007 allocs 181,014 allocs ⚪ 0%
text_100/ (ns/op) 230474.00 ns 229126.00 ns 🟢 -0.58%
text_100/ (B/op) 113.11 KB 113.11 KB ⚪ 0%
text_100/ (allocs/op) 4,985 allocs 4,985 allocs ⚪ 0%
text_1000/ (ns/op) 2.52 ms 2.51 ms 🟢 -0.14%
text_1000/ (B/op) 1.08 MB 1.08 MB ⚪ 0%
text_1000/ (allocs/op) 49,088 allocs 49,088 allocs ⚪ 0%
array_1000/ (ns/op) 1.30 ms 1.31 ms 🔴 +1.14%
array_1000/ (B/op) 1.13 MB 1.13 MB ⚪ 0%
array_1000/ (allocs/op) 12,884 allocs 12,883 allocs ⚪ 0%
array_10000/ (ns/op) 14.05 ms 14.35 ms 🔴 +2.11%
array_10000/ (B/op) 10.29 MB 10.29 MB ⚪ 0%
array_10000/ (allocs/op) 130,736 allocs 130,734 allocs ⚪ 0%
array_gc_100/ (ns/op) 139356.00 ns 143386.00 ns 🔴 +2.89%
array_gc_100/ (B/op) 104.20 KB 104.20 KB ⚪ 0%
array_gc_100/ (allocs/op) 1,372 allocs 1,372 allocs ⚪ 0%
array_gc_1000/ (ns/op) 1.48 ms 1.54 ms 🔴 +3.89%
array_gc_1000/ (B/op) 1.18 MB 1.18 MB ⚪ 0%
array_gc_1000/ (allocs/op) 13,932 allocs 13,932 allocs ⚪ 0%
counter_1000/ (ns/op) 204428.00 ns 210937.00 ns 🔴 +3.18%
counter_1000/ (B/op) 194.24 KB 194.24 KB ⚪ 0%
counter_1000/ (allocs/op) 5,773 allocs 5,773 allocs ⚪ 0%
counter_10000/ (ns/op) 2.18 ms 2.26 ms 🔴 +3.94%
counter_10000/ (B/op) 2.23 MB 2.23 MB ⚪ 0%
counter_10000/ (allocs/op) 59,780 allocs 59,780 allocs ⚪ 0%
object_1000/ (ns/op) 1.48 ms 1.53 ms 🔴 +3.51%
object_1000/ (B/op) 1.48 MB 1.48 MB 🔴 +0.02%
object_1000/ (allocs/op) 10,927 allocs 10,928 allocs ⚪ 0%
object_10000/ (ns/op) 16.82 ms 16.65 ms 🟢 -0.99%
object_10000/ (B/op) 12.75 MB 12.75 MB 🟢 -0.02%
object_10000/ (allocs/op) 111,237 allocs 111,229 allocs ⚪ 0%
tree_100/ (ns/op) 752159.00 ns 751691.00 ns 🟢 -0.06%
tree_100/ (B/op) 523.56 KB 523.55 KB ⚪ 0%
tree_100/ (allocs/op) 4,516 allocs 4,516 allocs ⚪ 0%
tree_1000/ (ns/op) 52.23 ms 51.48 ms 🟢 -1.43%
tree_1000/ (B/op) 43.74 MB 43.74 MB ⚪ 0%
tree_1000/ (allocs/op) 44,125 allocs 44,125 allocs ⚪ 0%
tree_10000/ (ns/op) 6.92 s 6.86 s 🟢 -0.79%
tree_10000/ (B/op) 4.30 GB 4.30 GB ⚪ 0%
tree_10000/ (allocs/op) 440,197 allocs 440,195 allocs ⚪ 0%
tree_edit_gc_100/ (ns/op) 2.71 ms 2.68 ms 🟢 -1.26%
tree_edit_gc_100/ (B/op) 2.40 MB 2.40 MB ⚪ 0%
tree_edit_gc_100/ (allocs/op) 10,765 allocs 10,765 allocs ⚪ 0%
tree_edit_gc_1000/ (ns/op) 214.78 ms 218.03 ms 🔴 +1.51%
tree_edit_gc_1000/ (B/op) 213.98 MB 213.98 MB ⚪ 0%
tree_edit_gc_1000/ (allocs/op) 107,148 allocs 107,144 allocs ⚪ 0%
tree_split_gc_100/ (ns/op) 1.95 ms 1.95 ms 🔴 +0.01%
tree_split_gc_100/ (B/op) 1.50 MB 1.50 MB ⚪ 0%
tree_split_gc_100/ (allocs/op) 8,134 allocs 8,134 allocs ⚪ 0%
tree_split_gc_1000/ (ns/op) 140.35 ms 139.80 ms 🟢 -0.39%
tree_split_gc_1000/ (B/op) 137.09 MB 137.09 MB ⚪ 0%
tree_split_gc_1000/ (allocs/op) 91,884 allocs 91,884 allocs ⚪ 0%
BenchmarkDocumentDeletion
Benchmark suite Previous Current Change
single_text_delete_all_10000/ (ns/op) 17.20 ms 17.51 ms 🔴 +1.80%
single_text_delete_all_10000/ (B/op) 10.82 MB 10.81 MB 🟢 -0.03%
single_text_delete_all_10000/ (allocs/op) 66,139 allocs 66,128 allocs 🟢 -0.02%
single_text_delete_all_100000/ (ns/op) 273.03 ms 269.54 ms 🟢 -1.28%
single_text_delete_all_100000/ (B/op) 107.93 MB 107.92 MB ⚪ 0%
single_text_delete_all_100000/ (allocs/op) 666,097 allocs 666,024 allocs 🟢 -0.01%
single_tree_delete_all_1000/ (ns/op) 52.37 ms 52.56 ms 🔴 +0.35%
single_tree_delete_all_1000/ (B/op) 44.68 MB 44.68 MB ⚪ 0%
single_tree_delete_all_1000/ (allocs/op) 51,198 allocs 51,201 allocs ⚪ 0%
single_text_delete_range_100/ (ns/op) 423534.00 ns 428351.00 ns 🔴 +1.14%
single_text_delete_range_100/ (B/op) 244.78 KB 244.80 KB ⚪ 0%
single_text_delete_range_100/ (allocs/op) 6,977 allocs 6,977 allocs ⚪ 0%
single_text_delete_range_1000/ (ns/op) 8.43 ms 8.50 ms 🔴 +0.89%
single_text_delete_range_1000/ (B/op) 6.39 MB 6.39 MB ⚪ 0%
single_text_delete_range_1000/ (allocs/op) 72,372 allocs 72,371 allocs ⚪ 0%
single_tree_delete_range_100/ (ns/op) 949052.00 ns 960915.00 ns 🔴 +1.25%
single_tree_delete_range_100/ (B/op) 710.27 KB 710.30 KB ⚪ 0%
single_tree_delete_range_100/ (allocs/op) 5,689 allocs 5,689 allocs ⚪ 0%
single_tree_delete_range_1000/ (ns/op) 61.27 ms 60.68 ms 🟢 -0.96%
single_tree_delete_range_1000/ (B/op) 54.53 MB 54.53 MB ⚪ 0%
single_tree_delete_range_1000/ (allocs/op) 56,427 allocs 56,428 allocs ⚪ 0%
BenchmarkRPC
Benchmark suite Previous Current Change
client_to_server/ (ns/op) 293.33 ms 289.82 ms 🟢 -1.20%
client_to_server/ (B/op) 12.40 MB 11.76 MB 🟢 -5.16%
client_to_server/ (allocs/op) 170,514 allocs 169,964 allocs 🟢 -0.32%
client_to_client_via_server/ (ns/op) 346.26 ms 353.83 ms 🔴 +2.18%
client_to_client_via_server/ (B/op) 20.99 MB 19.60 MB 🟢 -6.60%
client_to_client_via_server/ (allocs/op) 273,659 allocs 279,687 allocs 🔴 +2.20%
attach_large_document/ (ns/op) 1.36 s 1.34 s 🟢 -1.41%
attach_large_document/ (B/op) 1.88 GB 1.87 GB 🟢 -0.60%
attach_large_document/ (allocs/op) 10,789 allocs 10,790 allocs ⚪ 0%
adminCli_to_server/ (ns/op) 568.72 ms 566.30 ms 🟢 -0.43%
adminCli_to_server/ (B/op) 21.50 MB 21.49 MB 🟢 -0.05%
adminCli_to_server/ (allocs/op) 316,731 allocs 316,713 allocs ⚪ 0%
BenchmarkLocker
Benchmark suite Previous Current Change
(ns/op) 83.84 ns 87.54 ns 🔴 +4.41%
(B/op) 32.00 B 32.00 B ⚪ 0%
(allocs/op) 1 allocs 1 allocs ⚪ 0%
BenchmarkLockerParallel
Benchmark suite Previous Current Change
(ns/op) 45.27 ns 45.34 ns 🔴 +0.15%
(B/op) 0.00 B 0.00 B ⚪ 0%
(allocs/op) 0 allocs 0 allocs ⚪ 0%
BenchmarkLockerMoreKeys
Benchmark suite Previous Current Change
(ns/op) 179.40 ns 187.30 ns 🔴 +4.40%
(B/op) 31.00 B 31.00 B ⚪ 0%
(allocs/op) 0 allocs 0 allocs ⚪ 0%
BenchmarkRWLocker
Benchmark suite Previous Current Change
RWLock_rate_2/ (ns/op) 50.06 ns 50.46 ns 🔴 +0.80%
RWLock_rate_2/ (B/op) 0.00 B 0.00 B ⚪ 0%
RWLock_rate_2/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
RWLock_rate_10/ (ns/op) 44.88 ns 45.37 ns 🔴 +1.09%
RWLock_rate_10/ (B/op) 0.00 B 0.00 B ⚪ 0%
RWLock_rate_10/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
RWLock_rate_100/ (ns/op) 61.87 ns 64.55 ns 🔴 +4.33%
RWLock_rate_100/ (B/op) 2.00 B 2.00 B ⚪ 0%
RWLock_rate_100/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
RWLock_rate_1000/ (ns/op) 89.11 ns 90.06 ns 🔴 +1.07%
RWLock_rate_1000/ (B/op) 8.00 B 8.00 B ⚪ 0%
RWLock_rate_1000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
BenchmarkPresenceConcurrency
Benchmark suite Previous Current Change
0-100-10/ (ns/op) 1.69 s 1.70 s 🔴 +0.69%
0-100-10/ (B/op) 303.86 MB 308.67 MB 🔴 +1.58%
0-100-10/ (allocs/op) 5,044,788 allocs 5,036,209 allocs 🟢 -0.17%
100-100-10/ (ns/op) 2.87 s 2.95 s 🔴 +2.51%
100-100-10/ (B/op) 432.86 MB 432.51 MB 🟢 -0.08%
100-100-10/ (allocs/op) 6,858,891 allocs 6,861,579 allocs 🔴 +0.04%
300-100-10/ (ns/op) 5.56 s 5.62 s 🔴 +1.10%
300-100-10/ (B/op) 771.82 MB 787.40 MB 🔴 +2.02%
300-100-10/ (allocs/op) 12,668,994 allocs 12,690,008 allocs 🔴 +0.17%
BenchmarkChange
Benchmark suite Previous Current Change
Push_10_Changes/ (ns/op) 4.41 ms 4.39 ms 🟢 -0.29%
Push_10_Changes/ (B/op) 140.65 KB 140.86 KB 🔴 +0.15%
Push_10_Changes/ (allocs/op) 1,524 allocs 1,526 allocs 🔴 +0.13%
Push_100_Changes/ (ns/op) 18.48 ms 18.37 ms 🟢 -0.57%
Push_100_Changes/ (B/op) 767.78 KB 769.96 KB 🔴 +0.28%
Push_100_Changes/ (allocs/op) 8,773 allocs 8,768 allocs 🟢 -0.06%
Push_1000_Changes/ (ns/op) 150.26 ms 151.02 ms 🔴 +0.51%
Push_1000_Changes/ (B/op) 7.24 MB 7.46 MB 🔴 +3.07%
Push_1000_Changes/ (allocs/op) 83,152 allocs 83,163 allocs 🔴 +0.01%
Pull_10_Changes/ (ns/op) 3.21 ms 3.20 ms 🟢 -0.25%
Pull_10_Changes/ (B/op) 105.86 KB 105.90 KB 🔴 +0.04%
Pull_10_Changes/ (allocs/op) 1,122 allocs 1,121 allocs 🟢 -0.09%
Pull_100_Changes/ (ns/op) 5.42 ms 5.39 ms 🟢 -0.66%
Pull_100_Changes/ (B/op) 339.37 KB 339.29 KB 🟢 -0.02%
Pull_100_Changes/ (allocs/op) 4,759 allocs 4,758 allocs 🟢 -0.02%
Pull_1000_Changes/ (ns/op) 11.98 ms 11.16 ms 🟢 -6.88%
Pull_1000_Changes/ (B/op) 2.16 MB 2.15 MB 🟢 -0.22%
Pull_1000_Changes/ (allocs/op) 43,370 allocs 43,366 allocs ⚪ 0%
BenchmarkSnapshot
Benchmark suite Previous Current Change
Push_3KB_snapshot/ (ns/op) 21.90 ms 21.86 ms 🟢 -0.17%
Push_3KB_snapshot/ (B/op) 927.79 KB 912.69 KB 🟢 -1.63%
Push_3KB_snapshot/ (allocs/op) 8,779 allocs 8,775 allocs 🟢 -0.05%
Push_30KB_snapshot/ (ns/op) 155.59 ms 156.11 ms 🔴 +0.33%
Push_30KB_snapshot/ (B/op) 7.28 MB 7.44 MB 🔴 +2.08%
Push_30KB_snapshot/ (allocs/op) 83,161 allocs 83,255 allocs 🔴 +0.11%
Pull_3KB_snapshot/ (ns/op) 7.84 ms 7.75 ms 🟢 -1.11%
Pull_3KB_snapshot/ (B/op) 1.01 MB 1.01 MB 🟢 -0.08%
Pull_3KB_snapshot/ (allocs/op) 17,235 allocs 17,234 allocs ⚪ 0%
Pull_30KB_snapshot/ (ns/op) 19.28 ms 18.68 ms 🟢 -3.09%
Pull_30KB_snapshot/ (B/op) 8.37 MB 8.36 MB 🟢 -0.14%
Pull_30KB_snapshot/ (allocs/op) 168,506 allocs 168,506 allocs ⚪ 0%
BenchmarkSplayTree
Benchmark suite Previous Current Change
stress_test_100000/ (ns/op) 0.18 ns 0.18 ns 🟢 -1.32%
stress_test_100000/ (B/op) 0.00 B 0.00 B ⚪ 0%
stress_test_100000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
stress_test_200000/ (ns/op) 0.36 ns 0.36 ns 🟢 -0.14%
stress_test_200000/ (B/op) 0.00 B 0.00 B ⚪ 0%
stress_test_200000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
stress_test_300000/ (ns/op) 0.55 ns 0.56 ns 🔴 +2.02%
stress_test_300000/ (B/op) 0.00 B 0.00 B ⚪ 0%
stress_test_300000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
random_access_100000/ (ns/op) 0.01 ns 0.01 ns 🔴 +0.62%
random_access_100000/ (B/op) 0.00 B 0.00 B ⚪ 0%
random_access_100000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
random_access_200000/ (ns/op) 0.03 ns 0.03 ns 🟢 -6.24%
random_access_200000/ (B/op) 0.00 B 0.00 B ⚪ 0%
random_access_200000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
random_access_300000/ (ns/op) 0.05 ns 0.06 ns 🔴 +39.38%
random_access_300000/ (B/op) 0.00 B 0.00 B ⚪ 0%
random_access_300000/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
editing_trace_bench/ (ns/op) 0.00 ns 0.00 ns 🟢 -8.41%
editing_trace_bench/ (B/op) 0.00 B 0.00 B ⚪ 0%
editing_trace_bench/ (allocs/op) 0 allocs 0 allocs ⚪ 0%
BenchmarkSync
Benchmark suite Previous Current Change
memory_sync_10_test/ (ns/op) 7457.00 ns 7298.00 ns 🟢 -2.13%
memory_sync_10_test/ (B/op) 1.34 KB 1.34 KB 🟢 -0.07%
memory_sync_10_test/ (allocs/op) 35 allocs 35 allocs ⚪ 0%
memory_sync_100_test/ (ns/op) 56192.00 ns 57090.00 ns 🔴 +1.60%
memory_sync_100_test/ (B/op) 9.50 KB 9.49 KB 🟢 -0.03%
memory_sync_100_test/ (allocs/op) 268 allocs 267 allocs 🟢 -0.37%
memory_sync_1000_test/ (ns/op) 606725.00 ns 613021.00 ns 🔴 +1.04%
memory_sync_1000_test/ (B/op) 76.22 KB 76.11 KB 🟢 -0.14%
memory_sync_1000_test/ (allocs/op) 2,121 allocs 2,117 allocs 🟢 -0.19%
memory_sync_10000_test/ (ns/op) 7.95 ms 8.56 ms 🔴 +7.63%
memory_sync_10000_test/ (B/op) 750.86 KB 754.57 KB 🔴 +0.49%
memory_sync_10000_test/ (allocs/op) 20,367 allocs 20,413 allocs 🔴 +0.23%
BenchmarkSyncConcurrency
Benchmark suite Previous Current Change
1-100-10/ (ns/op) 15.27 s 15.26 s 🟢 -0.07%
1-100-10/ (B/op) 7.61 GB 7.63 GB 🔴 +0.22%
1-100-10/ (allocs/op) 157,789,497 allocs 157,834,636 allocs 🔴 +0.03%
100-100-10/ (ns/op) 16.62 s 16.52 s 🟢 -0.63%
100-100-10/ (B/op) 7.75 GB 7.76 GB 🔴 +0.19%
100-100-10/ (allocs/op) 160,115,034 allocs 159,976,512 allocs 🟢 -0.09%
300_100-10/ (ns/op) 19.26 s 18.88 s 🟢 -1.98%
300_100-10/ (B/op) 8.07 GB 8.06 GB 🟢 -0.24%
300_100-10/ (allocs/op) 165,652,971 allocs 165,654,770 allocs ⚪ 0%
BenchmarkTextEditing
Benchmark suite Previous Current Change
(ns/op) 5.91 s 6.02 s 🔴 +1.86%
(B/op) 3.90 GB 3.90 GB ⚪ 0%
(allocs/op) 20,542,674 allocs 20,542,648 allocs ⚪ 0%
BenchmarkTree
Benchmark suite Previous Current Change
10000_vertices_to_protobuf/ (ns/op) 5.09 ms 4.92 ms 🟢 -3.37%
10000_vertices_to_protobuf/ (B/op) 6.68 MB 6.68 MB ⚪ 0%
10000_vertices_to_protobuf/ (allocs/op) 90,026 allocs 90,026 allocs ⚪ 0%
10000_vertices_from_protobuf/ (ns/op) 232.65 ms 225.08 ms 🟢 -3.25%
10000_vertices_from_protobuf/ (B/op) 442.15 MB 442.14 MB ⚪ 0%
10000_vertices_from_protobuf/ (allocs/op) 280,046 allocs 280,045 allocs ⚪ 0%
20000_vertices_to_protobuf/ (ns/op) 10.83 ms 10.33 ms 🟢 -4.54%
20000_vertices_to_protobuf/ (B/op) 13.53 MB 13.53 MB ⚪ 0%
20000_vertices_to_protobuf/ (allocs/op) 180,029 allocs 180,029 allocs ⚪ 0%
20000_vertices_from_protobuf/ (ns/op) 896.90 ms 871.92 ms 🟢 -2.79%
20000_vertices_from_protobuf/ (B/op) 1.70 GB 1.70 GB ⚪ 0%
20000_vertices_from_protobuf/ (allocs/op) 560,076 allocs 560,077 allocs ⚪ 0%
30000_vertices_to_protobuf/ (ns/op) 16.03 ms 15.27 ms 🟢 -4.75%
30000_vertices_to_protobuf/ (B/op) 19.94 MB 19.94 MB ⚪ 0%
30000_vertices_to_protobuf/ (allocs/op) 270,031 allocs 270,031 allocs ⚪ 0%
30000_vertices_from_protobuf/ (ns/op) 2.00 s 1.99 s 🟢 -0.42%
30000_vertices_from_protobuf/ (B/op) 3.75 GB 3.75 GB ⚪ 0%
30000_vertices_from_protobuf/ (allocs/op) 840,123 allocs 840,122 allocs ⚪ 0%
BenchmarkVersionVector
Benchmark suite Previous Current Change
clients_10/ (ns/op) 131.37 ms 129.48 ms 🟢 -1.44%
clients_10/ (1_changepack(bytes)) 202.00 B 202.00 B ⚪ 0%
clients_10/ (2_snapshot(bytes)) 399.00 B 399.00 B ⚪ 0%
clients_10/ (3_pushpull(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_10/ (4_attach(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_10/ (5_changepack_after_detach(bytes)) 262.00 B 262.00 B ⚪ 0%
clients_10/ (6_snapshot_after_detach(bytes)) 156.00 B 156.00 B ⚪ 0%
clients_10/ (7_pushpull_after_detach(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_10/ (B/op) 7.64 MB 6.82 MB 🟢 -10.71%
clients_10/ (allocs/op) 58,169 allocs 58,158 allocs 🟢 -0.02%
clients_100/ (ns/op) 1.11 s 1.07 s 🟢 -3.52%
clients_100/ (1_changepack(bytes)) 202.00 B 202.00 B ⚪ 0%
clients_100/ (2_snapshot(bytes)) 3.10 KB 3.10 KB ⚪ 0%
clients_100/ (3_pushpull(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_100/ (4_attach(ms)) 7.00 ms 7.00 ms ⚪ 0%
clients_100/ (5_changepack_after_detach(bytes)) 263.00 B 263.00 B ⚪ 0%
clients_100/ (6_snapshot_after_detach(bytes)) 156.00 B 156.00 B ⚪ 0%
clients_100/ (7_pushpull_after_detach(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_100/ (B/op) 69.29 MB 75.74 MB 🔴 +9.31%
clients_100/ (allocs/op) 750,220 allocs 750,268 allocs ⚪ 0%
clients_1000/ (ns/op) 15.08 s 14.94 s 🟢 -0.98%
clients_1000/ (1_changepack(bytes)) 203.00 B 203.00 B ⚪ 0%
clients_1000/ (2_snapshot(bytes)) 30.10 KB 30.10 KB ⚪ 0%
clients_1000/ (3_pushpull(ms)) 5.00 ms 5.00 ms ⚪ 0%
clients_1000/ (4_attach(ms)) 25.00 ms 24.00 ms 🟢 -4.00%
clients_1000/ (5_changepack_after_detach(bytes)) 263.00 B 263.00 B ⚪ 0%
clients_1000/ (6_snapshot_after_detach(bytes)) 156.00 B 156.00 B ⚪ 0%
clients_1000/ (7_pushpull_after_detach(ms)) 5.00 ms 6.00 ms 🔴 +20.00%
clients_1000/ (B/op) 2.02 GB 2.02 GB 🟢 -0.17%
clients_1000/ (allocs/op) 36,352,790 allocs 36,350,605 allocs ⚪ 0%
BenchmarkWebhook
Benchmark suite Previous Current Change
Send_10_Webhooks_to_10_Endpoints/ (ns/op) 12.32 ms 12.02 ms 🟢 -2.43%
Send_10_Webhooks_to_10_Endpoints/ (B/op) 808.68 KB 808.13 KB 🟢 -0.07%
Send_10_Webhooks_to_10_Endpoints/ (allocs/op) 10,117 allocs 10,114 allocs 🟢 -0.03%
Send_100_Webhooks_to_10_Endpoints/ (ns/op) 120.54 ms 119.53 ms 🟢 -0.83%
Send_100_Webhooks_to_10_Endpoints/ (B/op) 8.08 MB 8.08 MB 🔴 +0.02%
Send_100_Webhooks_to_10_Endpoints/ (allocs/op) 101,156 allocs 101,157 allocs ⚪ 0%
Send_10_Webhooks_to_100_Endpoints/ (ns/op) 125.48 ms 121.84 ms 🟢 -2.90%
Send_10_Webhooks_to_100_Endpoints/ (B/op) 8.28 MB 8.26 MB 🟢 -0.27%
Send_10_Webhooks_to_100_Endpoints/ (allocs/op) 102,528 allocs 102,369 allocs 🟢 -0.16%
Send_100_Webhooks_to_100_Endpoints/ (ns/op) 1.24 s 1.24 s 🟢 -0.25%
Send_100_Webhooks_to_100_Endpoints/ (B/op) 82.46 MB 82.40 MB 🟢 -0.07%
Send_100_Webhooks_to_100_Endpoints/ (allocs/op) 1,022,373 allocs 1,022,419 allocs ⚪ 0%
Send_10_Webhooks_to_1000_Endpoints/ (ns/op) 2.77 s 2.74 s 🟢 -1.14%
Send_10_Webhooks_to_1000_Endpoints/ (B/op) 209.59 MB 209.60 MB ⚪ 0%
Send_10_Webhooks_to_1000_Endpoints/ (allocs/op) 1,716,577 allocs 1,716,471 allocs ⚪ 0%
BenchmarkWebhookWithLimit
Benchmark suite Previous Current Change
Send_10_Webhooks_to_10_Endpoints_with_limit/ (ns/op) 3.72 ms 3.69 ms 🟢 -0.82%
Send_10_Webhooks_to_10_Endpoints_with_limit/ (B/op) 306.52 KB 306.39 KB 🟢 -0.04%
Send_10_Webhooks_to_10_Endpoints_with_limit/ (allocs/op) 2,913 allocs 2,913 allocs ⚪ 0%
Send_100_Webhooks_to_10_Endpoints_with_limit/ (ns/op) 3.97 ms 3.95 ms 🟢 -0.68%
Send_100_Webhooks_to_10_Endpoints_with_limit/ (B/op) 428.92 KB 428.85 KB 🟢 -0.02%
Send_100_Webhooks_to_10_Endpoints_with_limit/ (allocs/op) 4,714 allocs 4,713 allocs 🟢 -0.02%
Send_10_Webhooks_to_100_Endpoints_with_limit/ (ns/op) 37.97 ms 36.88 ms 🟢 -2.87%
Send_10_Webhooks_to_100_Endpoints_with_limit/ (B/op) 3.08 MB 3.08 MB 🟢 -0.04%
Send_10_Webhooks_to_100_Endpoints_with_limit/ (allocs/op) 29,175 allocs 29,155 allocs 🟢 -0.07%
Send_100_Webhooks_to_100_Endpoints_with_limit/ (ns/op) 40.30 ms 39.99 ms 🟢 -0.76%
Send_100_Webhooks_to_100_Endpoints_with_limit/ (B/op) 4.37 MB 4.37 MB ⚪ 0%
Send_100_Webhooks_to_100_Endpoints_with_limit/ (allocs/op) 47,195 allocs 47,190 allocs 🟢 -0.01%
Send_10_Webhooks_to_1000_Endpoints_with_limit/ (ns/op) 370.82 ms 367.10 ms 🟢 -1.00%
Send_10_Webhooks_to_1000_Endpoints_with_limit/ (B/op) 44.51 MB 44.93 MB 🔴 +0.95%
Send_10_Webhooks_to_1000_Endpoints_with_limit/ (allocs/op) 380,128 allocs 380,446 allocs 🔴 +0.08%

@hackerwins hackerwins changed the title Adjust snapshot configurations Align snapshot confs to prevent excessive DB patching May 22, 2025
@hackerwins hackerwins merged commit f560ae5 into main May 22, 2025
6 checks passed
@hackerwins hackerwins deleted the presence-only branch May 22, 2025 08:12
@hackerwins

hackerwins commented May 22, 2025 •
edited
Loading

Copy link
Copy Markdown
Member Author
Screenshot 2025-05-22 at 5 21 26 PM

hackerwins added a commit that referenced this pull request May 22, 2025
@hackerwins
Adjust snapshot configurations (#1279)
d5127bb 
Previously, snapshots were stored every 3000 changes(SnapshotInterval),
and sent to new clients if pulled changes exceeded 500(SnapshotThreshold)
in PushPullChanges API. This mismatch led to a case where, with around
500 concurrent clients, a newly connected client might trigger the
server to fetch around 3000 changes from the database.

This change sets both the snapshot interval and change threshold to 500,
ensuring the server never needs to patch more than 500 changes at once.
@BrewTestBot BrewTestBot mentioned this pull request May 27, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@hackerwins-yorkie hackerwins-yorkie hackerwins-yorkie left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@hackerwins @hackerwins-yorkie