Update:
We've confirmed the issue... fixing it is taking more time than anticipated. – Kevin Montrose
Color me happy.
The throttle is now applied to api.stackoverflow.com so we have an undefined max requests per minute with an undefined burst allowance before 503 errors begin to be thrown.
It appears that the threshold has been raised significantly and interestingly it seems that the api.stackoverflow.com threshold is still higher than the other endpoints.
see What is the throttle interval or threshold? for current test results
Hey guys, we seem to be getting some love on the 503 throttle issue but need some help with some repro reports.
I have noticed just one other dev getting reports of 503 here, but trust me, if you haven't run into them yet it is just a matter of time and you will find yourself very frustrated and hacking in compensation code with something that does not resemble a smile on your face.
This is a critical issue and your help is needed to verify and prioritize this problem.
So please take a few moments and run this script while monitoring the requests in a tool like Fiddler for Windows or Charles proxy for Linux, MacOs and Windows to verify that the 503 is reproducible.
You don't need to download anything, simply paste this into a file and view it in a browser while monitoring via Fiddler or Charles.
An answer with your observations would be welcome but all that is really needed is a comment of repro/no-repro.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>NGINX Throttle Violations</title>
<script src="http://soapi.info/code/js/stable/scripts/Soapi.js" type="text/javascript"></script>
<script type="text/javascript">
var apiKey = 'qgAq_KfDu0KYzlNG-qaTuw';
// the error is easy to reproduce, but JSONP cannot handle http errors so
// you will have to run this script and watch in Fiddler.
// This behavior is quite consistent and if you are not seeing it then
// it may be likely that your IP is excluded from the throttling.
// set the queue interval from the semi-reliable default and painfully slow rate of 300ms to 10ms
// to expose the 503 errors to Fiddler
// comment this line to avoid 503 errors by throttling requests to the api to 1 every 1/3 second.
Soapi.RequestQueue.setInterval(10);
//Soapi.RouteFactory("api.stackoverflow.com", apiKey) // this endpoint behaves and dutifully returns 50 pages
Soapi.RouteFactory("api.stackapps.com", apiKey) // fails after 130 request burst
.Tags({ pagesize: 1 })
.getPagedResponse(null, null, function pageCallback(data)
{
// stop paged request after 50 pages or no more items
return data.page == 500 || data.items.length == 0;
});
</script>
</head>
<body>
</body>
</html>
Results
- Expected results by api.stackoverflow.com alt text http://img594.imageshack.us/img594/1862/200stackoverflow.png
- 503 throttling on api.stackapps.com alt text http://img101.imageshack.us/img101/8947/503stackapps.png
- 503 throttling on api.stackauth.com alt text http://img641.imageshack.us/img641/8687/503stackauth.png
Reference:
What is the throttle interval or threshold?
all api endpoints except api.stackoverflow.com are failing paged requests with HTML 503
stackauth throwing 503 (in html format) after just a few /users/{id}/associated requests
return data.page == 200...just to see what happens?api.stackoverflow.comendpoint behaves correctly as you described and dutifully returned me 256 pages with throttling disabled again.api.stackoverflow.combehaving different: this should in theory make it much easier to pinpoint the issue, as the Stack Exchange team should now about any such difference; of course it might turn out the exact opposite with this being a strange corner case due to their entire network setup treating the high volume site differently, be it explicitly or implicitly. Would be nice to get an official acknowledgment/comment regarding this important issue at least for a start ...