DXR Parallel Tree Indexing: Difference between revisions

Add motivations.
(Link to request-time-rendering bug.)
(Add motivations.)
Line 1: Line 1:
Once we have [https://bugzilla.mozilla.org/show_bug.cgi?id=1045183 request-time rendering] in place and no longer have to drag folders full of static HTML around the FS, indexing trees in parallel becomes feasible—something we'll need if we're going to scale up to dozens of trees. (I'm also assuming elasticsearch here.)
Once we have [https://bugzilla.mozilla.org/show_bug.cgi?id=1045183 request-time rendering] in place and no longer have to drag folders full of static HTML around the FS, indexing trees in parallel becomes feasible—something we'll need if we're going to scale up to dozens of trees. (I'm also assuming elasticsearch here.) Motivations:
 
# Reduce time to refresh the sum of all indexes so we can keep reasonably up to date.
# Don't let a broken build on one tree scuttle the indexing of the rest.


The config file is always going to exist, at least to point to the ES servers. These settings can stay there; changing them will require a WSGI restart:
The config file is always going to exist, at least to point to the ES servers. These settings can stay there; changing them will require a WSGI restart:
Confirmed users
574

edits