I just wanted to add to this. The 420s have let up for the most part and I'm
no longer seeing rate limiting behavior significantly different from the
norm.
I've noticed that many result pages are coming back with empty results but
if I re-request the same page (after a couple second delay), I can
Taylor,
Yeah this was definitely NOT good.In the past, when there is a
service disruption, your api group would post something on your status
page and tweet about it... Instead, I'm finding out about this from my
customers...
Did y'all tweet about this or present this somewhere where I could
By adjusting the rate limits to reduce the stress on your search api
without notice you have significantly increased the stress level on
our end :P Seriously, advanced notice of the situation would have been
welcome.
In particular what created lots of confusion on our end is that even
after
In many cases we are forced to change the rate limits in response to
a significant increase in requests, which means it isn't always possible to
give advanced notice of rate limit changes.
For some of you it sounds like your code that handles rate limiting didn't
react appropriately. When
Without prior notice, I can understand (circumstances), but without
any kind of subsequent announcement?? Means we have to discover issues
ourselves, verify that they're Twitter related (and not internal),
then search around for existing discussion on the topic. Saves us a
lot of time and
We're also seeing 400s on different boxes across different IP
addresses with different queries (so it does not appear to be server
or query specific). These began on all boxes at 2 a.m. UTC. We've
backed off on both number and rate of queries with no effect. We've
also noticed an increase in
We're working to reinstate the usual limits on the Search API; due to the
impact of the Japanese earthquake and resultant query increase against the
Search API, some rates were adjusted to cope better serve queries. Will
give everyone an update with the various limits are adjusted.
@episod
