[SERVER-82734] Improve capped collection write performance. Created: 02/Nov/23 Updated: 16/Nov/23 |
|
| Status: | Blocked |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Suganthi Mani | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
While investigatingĀ HELP-51123, I found some potential areas where we can improve the capped collection performance. Delete code path 1) Don't serialize capped deletes on secondaries.
2) Do batched deletion (like, PM-2227) before performing vectored inserts.
3) Another optimization to consider is using truncate instead of delete calls for substantial numbers of deletions. In 4.4, we used truncate when the number of documents to be deleted was > 3. Since, we were doing unreplicated implicit deletes in 4.4 and older version, this was simpler to handle corresponding index entry deletes. Since the start of 5.0, we've been using replicated delete, that might impose some challenges with index deletes. But, this may be worth exploring in PM-2983. Insert code path
2) Enable batch inserts on primary (see here and here)
|
| Comments |
| Comment by Steven Vannelli [ 16/Nov/23 ] |
|
Backlogging this until we finish PM-2983: Globally Unique, Replicated Record Ids to see what comes out of that project. |