Skip to content

Report NameRes latency per typing chain, not just per lookup #142

Description

@gaurav

The NameRes autocomplete notebook (#107) infers typing chains — consecutive lookups joined when they share a request shape, one query is a case-insensitive prefix of the other, and they fall within a tunable gap. That reconstructs diab -> diabe -> diabetes type 2 from individual log lines.

Right now the chains are purely descriptive: they exist to attach a final_query to each keystroke in the CSV export. But they are also the unit a user actually experiences. Nobody waits on one autocomplete lookup; they wait on the whole sequence while typing a term.

Worth promoting to headline metrics, and to the primary axis of the Solr-vs-ES comparison:

  • Total Solr wait summed across a chain (already computed as chain_solr_wait_ms, currently unused downstream).
  • The slowest single keystroke within a chain — the one that makes the box feel frozen.
  • Keystrokes per completed chain, i.e. how many round trips a single term costs.
  • How far into a chain the eventual final_query first appears in the top N results. If the right answer is already ranked first at diabe, the remaining lookups are pure cost, and that is a ranking question rather than a latency one.

Caveat to carry over: the logs have no session or user ID, so chains are inferred and the heuristic merges concurrent identical requests from different callers. Any chain-level metric needs to say so.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions