1

Update:

I am unable to reproduce the case of interactive browsing affecting app quota. And will concede that the failures that prompted this post were likely far edge cases.

The remaining issue of a badly behaved app failing and thus inducing a browsing DOS is not a bug in the throttle, simply a consequence of running a badly behaved (designed) app.

It was the other way around that concerned me i.e. interactive browsing eating app quota and inducing an all-around DOS.

I am not yet completely convinced that this is not a possibility, but until the throttle rate issues is cleared up, it is near impossible to write a test that can get reproduce what is admittedly and edge case (i hope).

The new throttle does not differentiate between programmatic API requests and requests made by a browser while viewing a Stack Exchange site.

This is a very serious issue.

The implication is that every app written against the API must warn the user not to view any Stack Exchange site while using (or x number of seconds before or after starting) the app or complete app and browsing failure could result.

Given the 'if you violate the throttle you, the response is undefined as are the consequences which could include being banned for an indeterminant period of time' (paraphrased, correct me if I am wrong) specification, this is best avoided.

Some have gone to extraordinary lengths to comply with the published throttle guidance, which I am not sure is yet accurate, and to lump the end-user's browsing activity in with the throttle quota is an impossible criteria to manage.

This behaviour was introduced with the new throttle and I can only assume that this is an oversight and hope that it will be resolved.

The obvious solution is to separate http://api.xxxx and http://xxxx requests from each IP into distinct quota buckets.

Repro

This issue can be reproduced by browsing a stack exchange site while running the throttle tests I have made available.

Granted, you will probably have to browse fairly quickly to ensure a failure in this test, but the point is that if an app is in the middle of a burst, say polling your (or your users) accounts and checking for data on those accounts, which most apps do, meanwhile you (or your users) are browsing a stack exchange site there is a possibility that a total DOS will occur.

Again, let me stress that is is not an issue of squeezing every single possible request per second from the API. It is about having a clearly defined specification that can be relied upon.

Lumping API traffic in with browsing traffic over which the developer has no control presents an unmanageable criteria.

Improve this question
12
  • @kevin - trip the wire with api requests and then try to browse a site. i think you will find a repro going that direction. the other direction is a less common story but the difference is academic.
    – Sky Sanders
    Commented Aug 29, 2010 at 1:00
  • 1
    @code poet - what you're describing is not a violation of the published throttle guidelines. If you "trip the wire" we reserve the right to do anything, which includes a network wide ban given that its a thing.
    – Kevin Montrose
    Commented Aug 29, 2010 at 1:09
  • @kevin - but it works the other way around, browsing while using an app, over which app developers have no control leading to an uncontrollable risk of denial to both the app and the browser. There is a clear delineation between api usage and web browsing.
    – Sky Sanders
    Commented Aug 29, 2010 at 1:15
  • @code: If you can point me to a JS page that pushes beyond the throttle, I'll give it a try and see if I can reproduce it.
    – Nathan Osman
    Commented Aug 29, 2010 at 1:19
  • @kevin and george, I am now having a hard time producing a repro case of browsing affecting api quota myself. Let me get back to you. this may be a non-issue.
    – Sky Sanders
    Commented Aug 29, 2010 at 1:29
  • @geo and kevin - confirm no-repro. George, your results from stackapps.com/questions/1457 would be appreciated.
    – Sky Sanders
    Commented Aug 29, 2010 at 1:42
  • @code: Okay, for '30 req. / 5 sec.', I got an error for request #31. For '30 req. / 5.5 sec.', I got an error for request #32. For '30 req. / 6 sec.', I got an error for request #31. And for '30 req. / 6.5 sec.', I got an error for request #31 again. Hope that helps... and I hope I did it right :)
    – Nathan Osman
    Commented Aug 29, 2010 at 6:40
  • @geo - that you are failing on the same request each time is weird and that you are getting a failure at all with 6.5 is even more weird, as this seems to be the current viable threshold. it sounds like you might not have waited 30 seconds between tests. if you go too early, before the throttle has cooled down, you get a delay but and an alert but no test is actually run - notice the first 2 lines in the log, they will tell you what rate is set for the Soapi throttle. If you could try it again and wait 30 seconds between tests you should get valid results. thanks for running the tests.
    – Sky Sanders
    Commented Aug 29, 2010 at 9:41
  • @geo - and it should be obvious that you should not have any other apps that use the API running when you test. That brings up another sticky issue for developers; what if a user is running more than one distinct app? hmmm.... looks like we have to add a warning line to an apps readme if our app is a quota hog. And could you please post your results as an answer on the other post?
    – Sky Sanders
    Commented Aug 29, 2010 at 9:45
  • @geo - and really, an app does not have to be a quota hog. 2 apps making 20 requests within 5 seconds of each other will kill them both and the browser. This makes a case for the most obvious solution of the api server introducing latency instead of forcing the developer to implement throttling, but that is another issue. The one at hand is determining if the current API throttle is operating to spec.
    – Sky Sanders
    Commented Aug 29, 2010 at 9:49
  • @code: Okay, I'll rerun them in a bit. One small sidenote: I was unable to reproduce the browser issue - what steps are needed for that?
    – Nathan Osman
    Commented Aug 29, 2010 at 16:25
  • @code: Hope my answer below helps... hope I'm not doing something wrong.
    – Nathan Osman
    Commented Aug 29, 2010 at 21:29

1 Answer 1

Reset to default
1

My results from this page: (being sure to wait 30 sec. between tests)

Rate:                   Failure point:
_________________________________________

30 req. / 5 sec.        Page 32
30 req. / 5.5 sec.      Page 32
30 req. / 6 sec.        Page 31
30 req. / 6.5 sec.      Page 31
30 req. / 7 sec.        Page 31

I also was careful on the last one to make sure no other apps where making requests 30 sec. before the test.

Improve this answer
4
  • interesting. you should not be failing @ 6.5. I wonder if there is a platform issue going on with Soapi.JS2. Could you copy the log results into an email? And for future reference, this stackapps.com/questions/1457 is the question we need to place results in. I am really interested in seeing the logs from the runs you made above - as well as from windows, next time you fire it up.
    – Sky Sanders
    Commented Aug 29, 2010 at 22:33
  • @code: I might not get to it 'till tomorrow, but I'll try to do that. Would you like me to try it in Firefox?
    – Nathan Osman
    Commented Aug 30, 2010 at 1:38
  • The results above are from Chrome.
    – Nathan Osman
    Commented Aug 30, 2010 at 1:38
  • It shouldn't matter but since you are on linux, yeah, FF is probably the safer bet. I hope I don't have a problem with linux/chrome. I would really like to see the logs. Thanks for helping.
    – Sky Sanders
    Commented Aug 30, 2010 at 2:21

You must log in to answer this question.

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