21

I was working on Blaze and noticed that I was getting quite a few of those nasty backoff violations. I checked my code for infinite loops and whatnot, then checked the dev console.

Here's the timeline:

  1. I call /answers with my key and a pagesize of 100. The exact path I call:

    https://api.stackexchange.com/2.2/answers?page=1&pagesize=100&key=p3YZ1qDutpcBd7Bte2mcDw((&site=stackoverflow&order=desc&sort=creation&filter=!LeJQlFEfIbsDDTG1lReSJX

  2. I get back a 10 second backoff parameter. On the first call. (I'm not hammering it, this is the first time I opened it today)

  3. I allow the user to disregard it (because I'm too lazy to build in a backoff checker gizmo) and the API hates me.

I don't really think that calling /answers should send a backoff on the first time. Sources also say that /posts does the same thing, but can't be repro'd on /questions.

Edit: Upon further testing, it seems I can only repro this behavior when making calls against Stack Overflow.

Another edit: I can repro this on this simple API call in the console - where I'm only asking for the single most recent answer, and I get a 10s backoff on the first try. This can't be right.

Improve this question
22
  • 5
    This is best asked on StackApps.com, the site for API support and applications built with the API.
    – Martijn Pieters
    Apr 18, 2014 at 16:51
  • 1
    Hey; if you stepped up too close to me too often, I'd tell you to stand back, too! ;)
    – Andrew Barber
    Apr 18, 2014 at 17:16
  • How many first calls have you made, actually, and in what time-frame?
    – John Dvorak
    Apr 18, 2014 at 17:42
  • Heh. @JanDvorak My first call today got a backoff. My first call yesterday got a backoff. And the day before that. Also, Tim Stone repro'd. Usually I make ~20 calls/day. These 'first calls' happened after at least 10 hours of silence.
    – Undo
    Apr 18, 2014 at 17:44
  • any chance you're on a shared IP?
    – John Dvorak
    Apr 18, 2014 at 17:45
  • Very little, @JanDvorak. And Tim repro'd, so the chances of both of us being on an IP with a crazy-API-abuser-guy are... insanely low.
    – Undo
    Apr 18, 2014 at 17:45
  • 1
    Hmm... I'm sending cca 200 requests per day to /answers/.../ and I'm yet to see a backoff. Could there be less backoff for anonymous apps than for registered ones?
    – John Dvorak
    Apr 18, 2014 at 17:49
  • 3
    I'm pretty sure the reason you're getting so much backoff is that you're ignoring it... it exists for a reason
    – Doorknob
    Apr 18, 2014 at 20:45
  • 2
    @Doorknob Doubtful. I should hope the API doesn't have a memory that lasts ten hours saying "give this guy a backoff every time"
    – Undo
    Apr 18, 2014 at 20:46
  • 1
    Why does it hold no water? The docs say "...it must wait that many seconds." There's no "if it's the first call of the day" or "if it's a...different kind of app."
    – Josh Darnell
    Apr 26, 2014 at 14:49
  • 1
    You shouldn't disregard the backoff. It's not really something you agree or disagree with.
    – Adam Lear StaffMod
    Apr 28, 2014 at 17:37
  • 8
    @AnnaLear While that's true (shame on Undo), it really doesn't make sense that the API considers this specific operation so much more expensive than all the others. Something must not be right there.
    – Tim Stone
    Apr 28, 2014 at 17:47
  • 8
    @AnnaLear It's not really conceivable that requesting the last n records of the posts table is somehow more expensive than requesting the last n records of the posts table which are also questions.
    – Tim Stone
    Apr 28, 2014 at 17:50
  • 2
    @AnnaLear Can I get another look at this? It's still happening and it's really annoying.
    – Undo
    Oct 16, 2014 at 21:51
  • 1
    Respected it on this IP, @AnnaLear, for at least a week. Returning a backoff on the first query on /answers for only one site seems really really odd to me.
    – Undo
    Oct 16, 2014 at 21:55

1 Answer 1

Reset to default
16

The API protects itself from heavy load to various subsystems that support it. In this case you were tripping a SQL server load throttle due to a very bad query plan due to a PostTypeId = @Answer rather than PostTypeId = 2 that snuck in there.

This has been corrected, and the new PostTypeId = {=Answer} (Dapper literal replacement) is live. You should no longer see a backoff. To get an idea of how bad this was...

Old query:

Table 'Users'. Scan count 0, logical reads 404.
Table 'Posts'. Scan count 1, logical reads 156368.
SQL Server Execution Times:
   CPU time = 8406 ms,  elapsed time = 9164 ms.

New query:

Table 'Users'. Scan count 0, logical reads 400.
Table 'Posts'. Scan count 1, logical reads 9460.
SQL Server Execution Times:
   CPU time = 15 ms,  elapsed time = 13 ms.

Your results should also now return just a tad bit faster.

Improve this answer
0

You must log in to answer this question.

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