Live search response time

I'm looking for research around acceptable response time for a live search feature that I can provide to my back-end team.

Some definitions:

• live search: results are automatically refined as the user types
• traditional search: the user types a full query and then explicitly invokes the search function (e.g. by pressing a button)

Of course, the ideal response time for live search is less than 100ms, and that's what you typically see in a consumer-oriented public web app. If I knew for sure I could get that kind of performance out of a back-end, I wouldn't even bother asking the question.

Because I'm working with a B2B app backed by legacy systems that have been in production for decades, <100ms is pretty much out of the question for now. So I'm trying to determine what's the maximum response time that would make live search feasible? At 200ms I know you lose the illusion that the system is responding instantaneously, but is that slow enough to interfere with the feedback loop of typing and getting results, so that live search either becomes unusable or so frustrating that users tend to prefer a traditional search? What about 400ms? What's the limit? Can we go all the way up to 1000ms?

I don't think a single target number is sufficient. The response time is not going to always be exactly the same, but will probably fit into a beta distribution.

If I specify the average response time, it could be that 3/4 of responses are well within the desired range the other 1/4 fan out far beyond that number. On the other hand, if I specify the maximum response time one long running query out of a thousand could spoil what is otherwise a successful test.

Hence, I intend to give the back-end team two performance parameters:

average response time: <250ms
95% of responses: <1000ms

I'm looking for any research or information that would help me refine those numbers and back them up with more than a hunch.