After applying the patch from https://www.drupal.org/project/search_api/issues/3178307, we have changes in related entities being re-indexed successfully.

However, in large databases, queueing search items to be re-indexed on the fly (save) can be a problem.

The timeout issue does occur in cases you have a large database with different indexes and lots of content entities.
For example, in my case, when I update a Degree Type taxonomy term that relates to around 80k entities it takes more than 40s for the page to save. This behavior on localhost is fine, however on an environment with 30s timeout that would error out.

I added code to measure getAffectedItemsForEntityChange and analyse how long $entity_ids = array_values($query->execute()); and the foreach block takes to execute and here is the output:

Anabranch Connect Index: Query time is: 0.022436141967773 seconds
Anabranch Connect Index: Foreach time is: 9.5367431640625E-7 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.0022249221801758 seconds
Anabranch Connect Index: Foreach time is: 2.1457672119141E-6 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.70239186286926 seconds
Anabranch Connect Index: Foreach time is: 4.6936919689178 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.75657796859741 seconds
Anabranch Connect Index: Foreach time is: 5.0897030830383 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.00897216796875 seconds
Anabranch Connect Index: Foreach time is: 0.011008977890015 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.0016090869903564 seconds
Anabranch Connect Index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.0016870498657227 seconds
Anabranch Connect Index: Query time is: 0.0022618770599365 seconds
Anabranch Connect Index: Query time is: 0.0014770030975342 seconds
Anabranch Connect Index: Query time is: 0.0016851425170898 seconds
Anabranch Connect Index: Query time is: 0.0016920566558838 seconds
Anabranch Connect Index: Query time is: 0.0030779838562012 seconds
Anabranch Connect Index: Foreach time is: 2.8610229492188E-6 secondsentity:group_content
Anabranch Connect Index: Query time is: 0.0025160312652588 seconds
Anabranch Connect Index: Query time is: 0.0022759437561035 seconds
Anabranch Connect Index: Query time is: 0.001176118850708 seconds

Article index: Query time is: 0.0018000602722168 seconds
Article index: Foreach time is: 3.0994415283203E-6 secondsentity:group_content
Article index: Query time is: 0.0027029514312744 seconds
Article index: Foreach time is: 2.1457672119141E-6 secondsentity:group_content
Article index: Query time is: 0.001784086227417 seconds
Article index: Query time is: 0.0018301010131836 seconds
Article index: Query time is: 0.0014579296112061 seconds
Article index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content

Career opportunity index: Query time is: 0.0017669200897217 seconds
Career opportunity index: Foreach time is: 3.0994415283203E-6 secondsentity:group_content
Career opportunity index: Query time is: 0.001643180847168 seconds
Career opportunity index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content
Career opportunity index: Query time is: 0.0016598701477051 seconds
Career opportunity index: Query time is: 0.0016038417816162 seconds

Course index: Query time is: 0.77181386947632 seconds
Course index: Foreach time is: 5.2628490924835 secondsentity:group_content
Course index: Query time is: 0.6846559047699 seconds
Course index: Foreach time is: 4.9171540737152 secondsentity:group_content
Course index: Query time is: 0.0065701007843018 seconds
Course index: Foreach time is: 2.8610229492188E-6 secondsentity:group_content
Course index: Query time is: 0.001978874206543 seconds
Course index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content

Employer index: Query time is: 0.0012490749359131 seconds
Employer index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content
Employer index: Query time is: 0.0016818046569824 seconds
Employer index: Query time is: 0.0014750957489014 seconds
Employer index: Foreach time is: 4.0531158447266E-6 secondsentity:group_content
Employer index: Query time is: 0.0014309883117676 seconds
Employer index: Foreach time is: 2.1457672119141E-6 secondsentity:group_content
Employer index: Query time is: 0.0015189647674561 seconds
Employer index: Query time is: 0.0051629543304443 seconds
Employer index: Foreach time is: 2.2172927856445E-5 secondsentity:group_content

Event index: Query time is: 0.0016829967498779 seconds
Event index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content
Event index: Query time is: 0.0017240047454834 seconds
Event index: Query time is: 0.0015909671783447 seconds
Event index: Foreach time is: 2.1457672119141E-6 secondsentity:group_content
Event index: Query time is: 0.0016031265258789 seconds

Institution index: Query time is: 0.0016078948974609 seconds
Institution index: Foreach time is: 2.1457672119141E-6 secondsentity:group_content

Scholarship index: Query time is: 0.007498025894165 seconds
Scholarship index: Foreach time is: 0.012362003326416 secondsentity:group_content
Scholarship index: Query time is: 0.0018000602722168 seconds
Scholarship index: Foreach time is: 3.0994415283203E-6 secondsentity:group_content
Scholarship index: Query time is: 0.0028719902038574 seconds

Story index: Query time is: 0.0017101764678955 seconds
Story index: Foreach time is: 3.0994415283203E-6 secondsentity:group_content
Story index: Query time is: 0.001784086227417 seconds
Story index: Foreach time is: 1.9073486328125E-6 secondsentity:group_content
Story index: Query time is: 0.0015840530395508 seconds

As you can see the "Anabranch Connect index" has more term references and that's why there are more queries being executed there. The time to execute the query doesn't seem like a huge issue. However, if you sum up the queries and loops time spent that is definitely something to be considered.

Comments

carolpettirossi created an issue. See original summary.

carolpettirossi’s picture

As per borrisson_ suggestion, I've created a patch adding the checkbox to index options and ignoring the indexes with the option disabled in trackReferencedEntityUpdate.

Search API - New Index option

I also implemented a hook_update to enable this option in all existing indexes by default.

drunken monkey’s picture

Component: General code » Framework
Status: Active » Needs work
Issue tags: +Needs tests
StatusFileSize
new5.57 KB
new5.14 KB

Thanks a lot for posting this again, looks like a sensible solution indeed. (Better would of course be to make this work for larger sites as well, but that’s much easier said than done. We’d probably need to integrate this with our task system for batch processing.)
Also, sorry for taking so long to respond, once again.

However, I think your suggested option key, label and description don’t really match what’s happening. Your text is written from the perspective of the changed entity, while the index has the perspective of the reindexed item – in other words, the entity referencing that changed entity. It’s also not about indexing, but about queuing for reindexing, or tracking the change.

My suggested key, label and description:

  • track_changes_in_references
  • Track changes in referenced entities
  • Automatically queue items for re-indexing if one of the field values indexed from entities they reference is changed. (For instance, when indexing the name of a taxonomy term in a Content index, this would lead to re-indexing when the term’s name changes.) Enabling this setting can lead to performance problems on large sites when saving some types of entities (an often-used taxonomy term in our example). However, when the setting is disabled, fields from referenced entities can go stale in the search index and other steps should be taken to prevent this.

The description is quite verbose, but I fear that it will otherwise be incomprehensible to most users. At the very least, they should be reasonable certain that they can safely ignore the setting.
Also, we should remember to add an even more verbose version of this to the documentation once we commit this.

Anyways, feedback would be very much appreciated, I’m sure the text can still be improved. (The functional changes, of course, look rather trivial. However, we should probably still add a test for this, too? Anyways, testing/review of those would also be appreciated.)

carolpettirossi’s picture

Sorry for the late reply @drunken monkey.

I totally agree with your feedback regarding label and description. It makes sense.

Unfortunately, I'm currently working on a different project and I'm not sure if I'll have some spare time anytime soon to implement the tests for this patch. Hopefully, we can get tests for this from another community member? Or perhaps, since it's a simple change (compared to the complexity of search_api) this could be committed without tests?

drunken monkey’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
StatusFileSize
new1.88 KB
new7.22 KB

No, just not adding a test is not an option. Especially with a module as complex as the Search API, it’s very important to have good automated test coverage – otherwise you end up breaking things with almost every change, at some point.

Anyways, adding a test was luckily almost trivial. Patch revision attached, please test/review!

drunken monkey’s picture

Status: Needs review » Fixed

Committed.
Thanks a lot again!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

vistree’s picture

Hi all, enabling "Track changes in referenced entities" on my Drupal 9.3 environment with search_api 8.x-1.21 causes problems when saving EXISTING content.
Everytime a edit a content page I get the unspecific error in watchdog: "Could not load the following items on index Content Index: "entity:node/1218:de", "entity:node/1218:en", "entity:node/1218:zxx"."

  • Initially ADDING the content page works without problems - the content is added to the search index
  • The content seems not to be added to search index in this case.
  • Clearing search index and running "Index now" works - and all content is added to the search index
  • Disabling the option "Track changes in referenced entities" makes the content being indexed on content save again.
renrhaf’s picture

Same as https://www.drupal.org/project/search_api/issues/3199906#comment-14398188, my logs seems to be filled up with errors related to this code.

[2022-03-19T00:31:00.147818+00:00] search_api.ERROR: Drupal\Core\Entity\Exception\UndefinedLinkTemplateException while attempting to find indexed entities referencing changed Paragraphe with ID "3461275" for index Commandes: No link template 'canonical' found for the 'paragraph' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 196 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php). {"severity_level":3,"exception":"[object] (Drupal\\Core\\Entity\\Exception\\UndefinedLinkTemplateException(code: 0): No link template 'canonical' found for the 'paragraph' entity type at /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php:196)"}

[2022-03-18T18:12:33.844544+01:00] search_api.ERROR: Drupal\Core\Entity\Query\QueryException while attempting to find indexed entities referencing changed Produit with ID "40229" for index Commandes: Invalid specifier 'product_id' in Drupal\Core\Entity\Query\Sql\Tables->addField() (line 314 of /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php). {"link":"<a href=\"/product/40229\" hreflang=\"fr\">Go to changed <em class=\"placeholder\">Produit</em> with ID \"40229\"</a>","severity_level":3,"exception":"[object] (Drupal\\Core\\Entity\\Query\\QueryException(code: 0): Invalid specifier 'product_id' at /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php:314)"}