qps rate exceeeded

[CharlesHarrison]

I am currently testing a web page that needs a very great deal of
testing indeed, as it's extremely complicated with many asynchronous
GETs from my own and other servers, as well as the odd look-up at
Google.

Recently, I've recently started to notice that postcode lookups are
failing. When I examine the GET in the Net tab of Firebug, I see the
message in the title in the response. The problem is clear enough,
but what can I do about it?

1) Is there any way within the client's JavaScript of working out that
this has occurred and alerting the user to try again later?

2) Is there any way of reducing the risk of occurrence?

[Jeremy Geerdes]

This message is coming from the Geocode API, which is a part of the Maps API rather than the Search/Language/Feeds/etc. APIs. That said, it is because the application in question is making too many geocode requests, too fast. Until a couple of months ago, the Geocode API allowed up to 15,000 requests per 24-hr period, based on IP address. This averaged out to 1 request every 6-ish seconds, and there were allowances for short bursts of higher volume where you could request 15-30 or so requests far quicker before the rate limit kicked in. More recently, though, the rate limit has been lowered to 2,500 requests per 24-hr period, still based on IP address. This equates to an average of 1 request every 35-ish seconds. Although the burst allowance is not documented anywhere that I've seen, I think that it has also been tightened dramatically so that applications simply can't make 25 geocode requests every time they load.

To be honest, though, even if they could make the burst geocodes at load time, such behavior would be far from preferable due to the performance hit that you're going to take for it.

The workaround is to geocode points once; store that data in a database, text file, the application itself, etc.; and then include the LatLng coordinates when the application loads in place of (or in addition to) the street addresses that were previously geocoded.

Jeremy R. Geerdes
Effective website design & development
Des Moines, IA

For more information or a project quote:
http://jgeerdes.home.mchsi.com
jrge...@gmail.com

If you're in the Des Moines, IA, area, check out Debra Heights Wesleyan Church!

> --
> You received this message because you are subscribed to the Google Groups "Google AJAX APIs" group.
> To post to this group, send email to google-ajax...@googlegroups.com.
> To unsubscribe from this group, send email to google-ajax-searc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-ajax-search-api?hl=en.
>

[CharlesHarrison]

On Oct 4, 1:31 pm, Jeremy Geerdes <jrgeer...@gmail.com> wrote:
> This message is coming from the Geocode API, which is a part of the Maps API rather than the Search/Language/Feeds/etc. APIs. That said, it is because the application in question is making too many geocode requests, too fast. Until a couple of months ago, the Geocode API allowed up to 15,000 requests per 24-hr period, based on IP address. This averaged out to 1 request every 6-ish seconds, and there were allowances for short bursts of higher volume where you could request 15-30 or so requests far quicker before the rate limit kicked in. More recently, though, the rate limit has been lowered to 2,500 requests per 24-hr period, still based on IP address. This equates to an average of 1 request every 35-ish seconds. Although the burst allowance is not documented anywhere that I've seen, I think that it has also been tightened dramatically so that applications simply can't make 25 geocode requests every time they load.

Yes, this is a recent phenomenon, so that agrees with your
description.

> The workaround is to geocode points once; store that data in a database, text file, the application itself, etc.; and then include the LatLng coordinates when the application loads in place of (or in addition to) the street addresses that were previously geocoded.

I can't do this, as the purpose of the page is to allow the user to
align a Terrestrial TV Aerial, given a postcode or other means of geo-
location. Over the weekend, I changed the system so that codes are
looked up at the UK Ordnance Survey first, and only those not found
there - Channel Islands, Northern Ireland, and Eire - will be sent
on to Google, so that will reduce the traffic, but that doesn't help
me to test all the system's various possible timings.

From within the client's JavaScript, how can I differentiate between
this situation and the postcode not existing?