Consider an Aggregate with 70.000 commits with a snapshot on 69.900 commits. The query issued to mongo to retrieve the last 100 commits is this one (grabbed from mongo profiling)
That can partially satisfy the previous query, because of the order of StreamRevisionFrom and StreamRevisionTo (inverted respect the index). This causes a full index scan for that aggregate.
When the system is under load, this can lead to poor performance. Possible solutions are
Change the query to issue StreamRevisionFrom and StreamRevisionTo into the correct order and verify that the index is now used effectively
Add another index (less preferable, because it wasted space and insertion time)
Created a patch in commit 08bd584e99e86e1af394e5511e835802b7a6cd3b in branch hotfix/5.3.4 but did not created unit test to confirm the increase of performance.
Consider an Aggregate with 70.000 commits with a snapshot on 69.900 commits. The query issued to mongo to retrieve the last 100 commits is this one (grabbed from mongo profiling)
Database has this index
That can partially satisfy the previous query, because of the order of StreamRevisionFrom and StreamRevisionTo (inverted respect the index). This causes a full index scan for that aggregate.
When the system is under load, this can lead to poor performance. Possible solutions are