Skip to content
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

SearchIndex::fieldData is inefficient #325

Open
NightJar opened this issue May 26, 2022 · 0 comments
Open

SearchIndex::fieldData is inefficient #325

NightJar opened this issue May 26, 2022 · 0 comments

Comments

@NightJar
Copy link
Contributor

On a large site it is reasonable it will also have a large index (or many small indices) amounting to a large and varied number of fields being indexed on a document.

SearchIndex::__construct calls init which in turn is intended to complete a full build of the index structure. The important components of this are addClass and addFulltextField, the latter of which relies upon fieldData which uses a complex series of introspection calls in nested foreach loops.

The consequence of this is that adding a single field of a not very complicated page type to a search index can take an extreme amount of execution time, e.g. nearly 4 seconds and over 350000 function calls to do it.

The consequence of this can be e.g. HTTP 500.

This is of particular bother as every index is built on every write procedure. E.g. browsing the CMS triggers a write operation for SilverStripe\Security\RememberLoginHash, which in turn is scanned by FulltextSearch to see if it needs to update an index (also in complete pointlessness, I should hope this is never indexed data for the purpose of site search).

Weirdly this seems to affect POST submissions much more than GET, and for some particular pages not others (e.g. UserDefinedForm page). But is a performance issue 100% of the time regardless of the end result in the specific use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants