You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Continuing a discussion from Discord, but gathering this all together to track outstanding tasks. The goal here is to reduce the overhead of appending events and Inline projections by reducing network round trips as much as possible. This is also to improve the new Quick Append event workflow and address #3310. This work is driven by scalability and performance concerns from two JasperFx clients concerned about scalability for very large workloads
Overarching changes:
Reproduce the optimization from Fetch for writing optimization for Inline projections #3290 that was backed out to make FetchForWriting() + Inline aggregates use an identity
map when loading the aggregate to avoid multiple database round trips. This time, make this behavior "opt in"
Reduce the network round trips when appending events to fetch stream state and/or aggregates
Event Appending Data Fetching
When appending events, there's potentially a series of preparatory data fetching steps that has to take place before the events
can be appended and any or all inline projections can be applied. Today this feature is very optimized for appending events to a single stream at a time -- which isn't necessarily how folks are actually using this feature today. To optimize the process -- and I'm making a very large assumption that reducing the network round trips to the database will more than offset extra in process steps -- I think we make the event appending be a multi-step process to create a new intermediate helper to enable data fetching like where the active IEventAppender and each registered Inline projection have a method something like:
publicinterfaceIEventAppendingStep{TaskApplyAsync(DocumentSessionBasesession,CancellationTokencancellation);}// This would be used to register data query needs in a batch, and return a "continuation"// that applies changes to the session laterpublicIEventAppendingStepFetchData(IBatchedQueryquery);
There's some more detail to this so there's some interplay between Inline projections that get the stream state for you
so you don't have to make a second fetch
Continuing a discussion from Discord, but gathering this all together to track outstanding tasks. The goal here is to reduce the overhead of appending events and
Inline
projections by reducing network round trips as much as possible. This is also to improve the new Quick Append event workflow and address #3310. This work is driven by scalability and performance concerns from two JasperFx clients concerned about scalability for very large workloadsOverarching changes:
map when loading the aggregate to avoid multiple database round trips. This time, make this behavior "opt in"
Event Appending Data Fetching
When appending events, there's potentially a series of preparatory data fetching steps that has to take place before the events
can be appended and any or all inline projections can be applied. Today this feature is very optimized for appending events to a single stream at a time -- which isn't necessarily how folks are actually using this feature today. To optimize the process -- and I'm making a very large assumption that reducing the network round trips to the database will more than offset extra in process steps -- I think we make the event appending be a multi-step process to create a new intermediate helper to enable data fetching like where the active
IEventAppender
and each registeredInline
projection have a method something like:There's some more detail to this so there's some interplay between
Inline
projections that get the stream state for youso you don't have to make a second fetch
Tasks
QuerySession.UseIdentityMapFor<T>()
changes from Fetch for writing optimization for Inline projections #3290StoreOptions.Events.UseIdentityMapForInlineAggregates
, with the default being falseFetchForWriting()
using anInline
aggregate should opt into using the identity map if the above setting is trueUseIdentityMapForInlineAggregates
is turned onUpsertFunction
to reflect the aboveStreamAction.PrepareEvents()
from 0630f55DocumentMapping.UseVersionFromMatchingStream
from 0630f55UpsertFunction
from 0630f55 after the reset to 0The text was updated successfully, but these errors were encountered: