You can only perform 4 searches within a minute

Just got this message from stackoverflow. I agree that there must be a limit to prevent abuses, but 4 searches/minute seems way too restrictive, it makes search almost useless when trying to refine (IMHO a common pattern in searching)

  • I hope you don't mind that I changed this into a [feature-request] to increase the searches per minute. – user27414 Mar 22 '11 at 21:19
  • 4
    If you are forming searches at a rate of one per 15 seconds, you may want to consider thinking a little more about what you're really searching for, and searching less frequently. Alternately, when you find you have to search at this rate, consider using google. – Adam Davis 'ze-zir-zem' Mar 22 '11 at 21:23
  • @status-declined: thanks – Mauricio Scheffer Mar 22 '11 at 21:47
  • 4
    @Adam: I disagree... searching in SO should be more precise than googling. Lucene is fast, I don't see any reason to limit this to 4 searches per minute. – Mauricio Scheffer Mar 22 '11 at 21:50
  • 1
    Don't forget about the Data Explorer - endless flexibility. – uɐɯsO uɐɥʇɐN Oct 29 '11 at 3:11
  • Meanwhile, the limit is effectively gone altogether. – Arjan Jan 26 '13 at 16:04

Since the new search was introduced in December 2012, there is no real limit for humans anymore.

March 2011:

In the next build we'll up this to 6 searches/min, but we may tweak it in either direction depending on how usage goes. It's not a super-cheap operation, so we don't want it to be an abuse point in the system.

Remember: paging doesn't count against this limit. But searches that have no result do count.

And for future searches:

You can only perform 6 searches within a minute, please wait a minute then try again.

  • 1
    It seems that sorting counts as a new search too? Like when I know something has been asked recently, and hence I want to sort on "newest", all of my searches count as two... – Arjan Apr 18 '11 at 17:38
  • 1
    It seems that searches that have zero results count too? I quite often hit this message. :-( – Arjan May 8 '11 at 11:33
  • @Arjan - This is correct, it's a server load being sane issue, we may increase it more later...but no matter how many results come back there's still a fair amount of load involved on the IO side at the moment...we're working on this :) – Nick Craver May 8 '11 at 11:45
  • Thanks, @Nick. As for sorting: I am not sure if clicking "newest" runs a new query? If it does, then maybe it helps if the search remembers the last sort order? Any new search always gets one "relevance" first. – Arjan May 8 '11 at 11:49
  • 6
    Could this be increased to 10? I occasionally hit the limit, and it's a tiny bit annoying. – Pekka supports GoFundMonica May 12 '11 at 7:13
  • 2
    I don't suppose it would be possible to treat changing through the different tabs or changing pages as part of the original search. Usually the first thing I do when I perform a search is switch to the votes or newest tab. That act alone makes a single search count as two. And more often than not, I will switch to another tab or go to the next page. There goes another set of "searches." – Jeff Mercado May 12 '11 at 8:01
  • 1
    @Pekka's - Starting in the next build paging will also not count against the throttle, that should reduce the impact quite a bit. Also, it's not sliding. Once we change out some hardware and the IO cost isn't as big of a deal here we may increase it. – Nick Craver May 12 '11 at 12:57
  • @Jeff - In the next build tabs/pages will not count, since that's not where the main (IO) cost is currently I've put a bit more handling in for that. – Nick Craver May 12 '11 at 12:58
  • 9
    It would be REALLY helpful if the limit was relaxed for searches with no hits. Otherwise using standard search term refinement approaches will quickly run afoul of the limit. – Kevin Dente Jun 9 '11 at 2:36
  • I knew it was an expensive operation! meta.stackexchange.com/questions/135021/… – ajax333221 Jun 19 '12 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .