We're doing that as well, queing up requests (we have to support searching thru GPRS phones so it's quite stringent). One of the keys is managing the size. But if the idea is to make an interactive search field, introducing a delay (and I'd go over .2 secs easily) is the key. You might want to affect user's perception by showing a progress icon of some sort before the threshold... something like:
-------- Original Message --------
Subject: Re: Canceling submitted request
From: Alex at Ikanow <firstname.lastname@example.org>
Date: Mon, August 01, 2011 6:23 pm
To: elasticsearch <email@example.com>
Hi, in case it's useful: what I did in response to the problem you
discussed was only allow 1 "search suggest" request to be active at
any one time.
1] So if I type 'a', my client fires a search request
2] I type (a)'l': this request is stored but not sent (because the
response to 'a' has not yet returned)
3] I type (al)'e': this request is stored, overwriting 'al' with 'ale'
4] The response for 'a' appears ... I immediately send out the request
for 'ale', then display the results
5] I type (ale)'x', this request is stored but not sent (because the
response to 'ale' has not yet returned)
That way regardless of how fast the user types, they can only have to
wait for (worst case) 2 requests to return, and there is no risk of
overloading the server with "useless" requests
This has worked really well in practice for me, though of course it is
- the number of users you have concurrently typing into the search
Hope this helps!
On Aug 1, 4:13 pm, Michael Feingold <mfeing...@hill30.com> wrote:
> Is there a way to cancel a previously submitted search request?
> Here is why: I want to give a list of suggestions as they type the
> search parameters. But I do not really want to show/update it until
> the user pauses in his typing. Now I implemented a sliding timeout - I
> do not submit the request until after .2 sec of the last keypress,
> which is my definition of pause in the typing, but it means that I
> add .2 sec to the search time.
> Removing the delay will generate a ton of requests I care nothing
> about, but if I can cancel it as soon as I get the next keypress -
> there is not much harm done.
> Any thoughts?