Why aren't nodes indexed when they are saved?

As we all know, node_update_index is invoked by search_cron, which means that the search index is only updated as frequently as cron runs.

I am curious why _node_index_node isn't part of the normal node_save process, eg

if ($node->status == NODE_PUBLISHED) {

Is there a good reason for this? Since this function is defined by the node module itself, I don't see how it is a separation of responsibilities thing, nor can I think of a good reason for not doing this.

The related question would be, is is safe to wire up an action to fire when a node is created or updated?

  • Think in VBO demoting from front page a thousand of nodes, one little click for a user, but a big process for the system. – user24010 Nov 26 '13 at 15:37

I believe it is in the interest of scalability. Imagine you had a large, popular site with user-generated content. Imagine you had users saving a node (say, posted a question or answer) every 20 seconds. Imagine a node being indexed as well as submitted every 20 seconds. The site would become unusable very quickly. So it's much better to allow the indexing to happen independently of node submission.

| improve this answer | |
  • I would counter by saying that you are only indexing a single node and not the whole site when you save. Saving a node is already an expensive process. – mpdonadio Jun 25 '12 at 15:07
  • 2
    Indexing text for search is often as expensive as the rest of the node save process, and would add even more time to the save operation (causing the site to feel slower, since the next page wouldn't load until indexing is complete). Using a separate search system (like Solr) will make things better all around :) – geerlingguy Jun 25 '12 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.