-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Mango to reduce the number of indexes needed client side #5592
Comments
The impacts of convert a set of indexes to Mango were evaluated for feasibility and impact. In the first round of evaluations, the six MapReduce views which are warmed during bootstrap were evaluated. Feasibility
Performance Metrics for medic-client/formsExecution Times - Measured via 100x tight loop
Scripts:
Build PouchDB Index - Based on sample of 3 measures
Scripts:
Other Metrics
Measure IndexedDB Disk Use (Chrome 70 only): Bandwidth Scripts:
ConclusionsBased on these findings, Mango is not particularly well suited to help with the WebApp's bootstrapping. It is likely that Mango is better suited for use outside of the webapp's performance hot paths. Some potentially fruitful options are to use it in API/Sentinel. Or within WebApp, the filtered search indexes should be investigated as well as less hot performance code paths like editing user settings ( To help scope down 3.7, and because it is believed that IDBNext is likely to impact the performance characteristics of Mango and indexing - it was recommended that this investigation be continued after the IDBNext work. |
Chatted to Kenn. Things to try in the future:
|
Deferring to 3.9.0 |
Let's wait for IDBNext to land and then run this again. |
We currently query for data records in PouchDB / CouchDB via mapreduce queries.
Each map-reduce defined query creates its own index that needs to be kept up to date as data changes.
Mango splits the creation of the index from the use of it in a query. So, if we can convert many of our mapreduce queries to Mango, we can reduce how many indexes that need to be generated.
An example of looking at this for startup is here: #5264 (along with some other changes)
We need to be careful and measure performance, in both offline and online situations, both for query speed and individual index generation time, as well as network costs in the online scenario, and balance that against the fact that Mango allows for less indexes. It's complicated!
One core difference is that Mango queries are always equivalent to
include_docs: true
in relation to how CouchDB pulls data off disk into memory. One example of how this affects things is that a mapreduce view which doesn't include_docs will query much faster than the equivalent Mango query, when running in CouchDB (PouchDB should be equivalent).The core goal is to reduce the count of indexes generated locally, while making sure we do not accidentally degrade performance elsewhere.
The text was updated successfully, but these errors were encountered: