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
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.
The text was updated successfully, but these errors were encountered:
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
callsinit
which in turn is intended to complete a full build of the index structure. The important components of this areaddClass
andaddFulltextField
, the latter of which relies uponfieldData
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.
The text was updated successfully, but these errors were encountered: