Closed Bug 1010561 Opened 10 years ago Closed 10 years ago

rethink backoff algorithm for search suggestions

Categories

(Firefox :: Search, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1007979

People

(Reporter: mconnor, Assigned: mconnor)

References

Details

Attachments

(1 file)

Attached patch revisedSuggestBackoff (deleted) — Splinter Review
The current algorithm dates from 2006, when suggestions were a new thing and we didn't know how well the services would stay up. It was also a "new" thing that wasn't an expected part of the search experience, so being conservative about things felt like a good idea. It has some weird attributes, not least of which is that after each backoff period we have to fail three times before we re-enter backoff. It also backs off for a minimum of ten minutes, which seems excessive in this day and age. Considering the modern standard for web services is five nines, or less than five minutes per _year_, this seems excessive except in worst-case scenarios. As a more modern version, I'd propose that we implement the following modified algorithm: * Backoff interval should be set as 2 ^ N seconds starting with the first error, where N is the number of consecutive errors we've hit. Odds are if we've hit a backoff situation, we should at least wait a few seconds even on the first hit. We'll still show local matches in this case. * Maximum backoff interval should be one hour. Even in an extreme case, retrying once per hour should be an acceptable maximum. Note that this interval would take 12 consecutive failures to reach, or 1:08:14 of wall clock time at theoretical minimum, and almost surely longer for any normal user (especially when it's unlikely that suggestions would fail, but search itself wouldn't, for an extended period of time) * Timeouts should be interpreted as errors for the purpose of entering backoff mode. I'll note that, to the best of my digging, Chrome doesn't have _any_ backoff code in place in suggestions, they just log failure normally and move on. Unless they've centralized backoff handling in their network code, and I didn't find that either.
Attachment #8422752 - Flags: review?(gavin.sharp)
I guess I don't feel a strong need to revisit this unless we have evidence it's misbehaving/suboptimal in practice? Some telemetry on how often we hit backoff might be useful.
I'd also prefer removing the backoff code entirely to writing a new custom version.
Honestly, I'd also prefer that. I'm not sure if we ever hit this. Maybe morph to removing backoff, and recording errors for Telemetry?
Attachment #8422752 - Flags: review?(gavin.sharp) → review-
The backoff code was removed in bug 1007979. Do we want to add telemetry here or possibly add it back in a different form? If not, we can dupe to bug 1007979.
Flags: needinfo?(mconnor)
Honestly, given that other browsers don't even bother, I'm inclined to just dupe it, and if we have problems we can revisit.
Flags: needinfo?(mconnor)
Done duped.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: