We don’t have multiple installations, so that’s not the issue in our case.
Paul Howard is right about multiple issues. We have had various search issues over time, and my post reflected that. Thus, being able to find items by title but not by content ID is not a current issue. Equally, in the past, indexing has seemingly failed altogether. In summary then, because of past experience we are concerned by the vulnerability of indexing, which is a key process, and with indexing not happening in a timely way, which is the case again now but not necessarily for the same reasons as previously.
Paul Howard’s indication of a five second index time is consistent with our experience, and in my view that in itself is a problem. Typical editor behaviour is to create an item, and then immediately to create/edit another that depends on the first (say an image, then a page that includes it, or a page, then another that links to it or uses one of its variants). Thus, any item must always be fully-indexed in less than the time taken to start work on another. In some cases, we are probably talking about a thirty-second maximum. Any failure to meet this timescale results in loss of editor confidence in the system, and involves editors in understanding under-the-hood processes from which Rhythmyx is supposed to protect them.
That’s fine if you’ve got one editor on the system and nothing delays things, as five seconds is plenty quick enough. However, on one of our sites we are now running imports from an external data source. That puts a couple of thousand items, each with four events, so eight thousand items in the queue, and an eleven hour delay. We can run the import off-peak, but we are supporting 24*7 international editing. We can also work to make the import more efficient (changed items only instead of a full import) - but even ten items are going to push us over the thirty-second target above.
We’ve investigated the current issue more since I first posted, and found a substantial number of corrupted items in the PSX_SEARCHINDEXQUEUE table, so we have cleared that and restarted, and we are currently running a full reindex. We’re also aware of the need to make sure that the RXSERVER user has appropriate privileges. However, in view of the above, it seems likely that even a fully-operating system will not meet editors’ reasonable expectations.
In summary, five seconds is an enormous time to index one item!