Cancel Superseded Searches
While a shopper types into the search box, the dropdown sends a new search for almost every keystroke. Without help, every one of those searches runs to the end on your database server, even though the shopper only ever sees the last one. Cancel Superseded Searches stops the earlier keystroke’s database query as soon as the next keystroke’s search arrives, so the server works on one dropdown search per search box instead of a queue of them.
Available since 5.95.0.
Where to find it
Go to Super Speedy Search > Front-end. Cancel Superseded Searches sits directly under Fast Ajax. It is a single checkbox, off by default, with an optional time limit underneath:
| Control | Default | What it does |
|---|---|---|
| Cancel Superseded Searches | Off | Each keystroke’s dropdown search stops the previous keystroke’s query for that search box |
| Stop a dropdown search after … seconds | 0 (no limit) | Stops any dropdown search still running after this many seconds. Accepts 0 to 120 |
It works with the normal REST dropdown and with Fast Ajax. No rebuild is needed, and turning it on or off does not empty the search cache.
What happens while a shopper types
Take a shopper typing “red dress”. The dropdown sends searches for “red”, “red d”, “red dr” and so on, each a fraction of a second after the last. With the setting on:
- Each search box gets its own search session for the page view, and every request carries its place in the typing order.
- When a newer search arrives, it stops the older searches from the same box that are still running on the database.
- If an older request arrives late, after a newer one has started, the older one stands down instead of stopping the newer one. The shopper always gets results for what they typed last.
- A stopped search returns no results to the browser, which has normally moved on to the next request anyway. It is not cached, not counted in Analytics & Caching and not written to the error log.
Searches from other shoppers, other search boxes and other post types are never touched. The full search results page is not affected either; this setting only covers the dropdown’s results.
The session travels in a request header, not in the URL, so a CDN or edge cache that caches dropdown responses by URL keeps sharing identical searches between visitors.
The saving is on the database server, not in the browser. A shopper typing quickly on a large catalogue can otherwise leave several slow dropdown queries running at once, and on a busy store those pile up across every shopper who is typing. With this on, each search box has at most the current search and the one it is stopping.
When to switch it on
- Large catalogues where a dropdown search takes long enough to overlap the next keystroke
- Busy stores where many shoppers type into the search box at the same time
- Database servers that show several identical-looking search queries running together in their process list
- Small catalogues where every dropdown search finishes before the next keystroke: there is nothing to stop
- Sites whose database sits behind a connection pooling proxy such as ProxySQL or MaxScale: the setting detects this and switches itself off
The optional time limit
Stop a dropdown search after … seconds applies only while Cancel Superseded Searches is ticked. 0, the default, means no limit.
Set a limit and any dropdown search still running after that many seconds is stopped. The shopper sees no dropdown results for that post type on that keystroke, and the next keystroke searches again as normal. Each stopped search writes one line to the PHP error log, naming the post type, how long it ran and the limit:
Super Speedy Search: dropdown search for post type product stopped after 1001 ms by the 1 s time limit (Cancel Superseded Searches setting)The line carries no search terms, so shoppers’ searches stay out of your server log.
Do not set the limit lower than your slowest genuine search. A broad search such as a single common word can legitimately take several seconds on a very large catalogue, and a tight limit turns that into an empty dropdown. Check the error log after setting a limit: a steady stream of lines means the limit is too low.
When it switches itself off
Stopping another request’s query safely needs the database to show which connection is running which statement, and to accept a request to stop it. Before it stops anything, the plugin checks your environment. It turns cancelling off for the whole site, and records why, when it finds any of these:
- A connection pooling proxy, such as ProxySQL or MaxScale, answers for the database, or the connection ID changes between two statements. A pooling proxy can accept a stop request without passing it on, so the setting would do nothing useful.
- The database refuses the stop request, for example because the statement belongs to a different database user.
- The process list does not show this connection, which happens with a restricted process list or with pooling.
- A multi-connection database drop-in, such as HyperDB or LudicrousDB, can send statements over different connections.
- The database driver is not mysqli, as with an SQLite integration.
Searches carry on as normal in every case; only the cancelling stops. The reason shows as a warning under the setting on the Front-end tab:
Turned off automatically on date and time because reason. Save these settings with the box ticked to try again.
If you have fixed the cause, for example by connecting WordPress to the database directly instead of through the proxy, save the settings with the box still ticked and the plugin checks again.
Troubleshooting
The dropdown sometimes shows nothing for one keystroke. That is the time limit at work. Raise it, or set it back to 0, and check the PHP error log for the lines described above.
The warning says it was turned off automatically. Read the reason in the warning. Pooling proxies and multi-connection drop-ins are permanent features of a hosting set-up, so on those sites leave the setting off.
Nothing seems different. On a catalogue where each dropdown search finishes before the shopper’s next keystroke, there are no overlapping searches to stop. The extra work per dropdown request is one short lookup in the database’s process list, so leaving it on does no harm.
Further reading
Written for Super Speedy Search 5.95.0.
Comments