Today, CRUD Ops are implemented by nearly all of the ~19 OpObservers.
For onUpdate:
- 4 are too complicated to filter at all and should be called every time
- 10 could filter on one namespace
- 1 could filter on two namespaces
- 1 could filter on three namespaces
- 1 could filter on four namespaces
- 1 could filter solely on update.isEmpty
onInserts, aboutToDelete, and onDelete are a similar story with similar amounts of namespace filtering.
By filtering on namespace in the registry, we can eliminate many unnecessary virtual function calls for each CRUD op in the server.
Furthermore, I noticed that all namespace filtering in OpObservers can be fit into three categories:
- always run (e.g. OpObserverImpl, for logging to oplog and other system-critical functional behavior)
- observe changes to the internal config database (config.*)
- observe changes to internal system collections (.system.)
- is depended on by
-
SERVER-77057 Investigate slow down caused by OpObservers in updateMany code path
-
- Closed
-
- is related to
-
-
- Closed
-
- related to
-
SERVER-77927 Profile OpObserver Perf Improvements
-
- Closed
-
-
SERVER-77373 Use OpStateAccumulator's to cache common state
-
- Backlog
-
-
-
- Closed
-