Error 403: Quota Error: profileId ga:NNNNNNN has too many concurrent connections.

[Luis]

Hi there,

 

We are using Core Reporting API 3.0 and since yesterday we started to receive a lot of 403 errors: Quota Error: profileId ga:NNNNNNN has too many concurrent connections

 

We have beed suffering this error for multiple profiles, and we are far from reaching any of the existing quotas:

 

  10 queries per second (QPS) per IP

  10,000 requests per profile per day
  10 concurrent requests per profile

 

Is any one facing this issue as well?

 

Thanks in advance

[Anthony Bliss]

Also receiving this error as of 07 June 2012. No information or insight available :(

[shumisha]

Hi
Also experiencing this error all of a sudden from today (June 8) midday. This is with API V 2.4.
As per posts found elsewhere, I changed the per user/per IP allowance to 10.0/sec in the API console, as it is set to 1.0/sec by default, when the API project is created.

This didn't have any immediate effect, as I'm still receiving the error. I will allow some time though, as some time may be required for the setting change to propagate?

Rgds

[Nick]

Hi,

If you are making too many concurrent connection to the API, then you will get this error below. What that means is that you need to slow down the number of requests you make to our service and retry the queries that generated the 403s at a later time.

Yes, our quota HAS changed from 2.3 -> 2.4, so for a small number of apps, some logic to control quota might need to change.

After you retry, and can consistently reproduce getting a 403 error, you can send me your profile id and we can take a look.

-Nick

[Luis Pereira]

Well, the issue that we are facing is getting punctually this error while being far away from the threshold. We make no concurrent connection for a given profile and queries are enough distributed in time. That's why we raised this question, to check whether other people are facing what we thought it could be an issue for v3 API as well as the strange and punctual 503 backend error a few people have reported. 

Thanks,

Luis

--
You received this message because you are subscribed to the Google Groups "GA Data Export API" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-analytics-data-export-api/-/uwZPY4BkUMoJ.
To post to this group, send email to google-analytics...@googlegroups.com.
To unsubscribe from this group, send email to google-analytics-data-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-analytics-data-export-api?hl=en.

[Nick]

can you send me your project ID.

-Nick

On Friday, June 8, 2012 9:42:03 AM UTC-7, Luis wrote:

Well, the issue that we are facing is getting punctually this error while being far away from the threshold. We make no concurrent connection for a given profile and queries are enough distributed in time. That's why we raised this question, to check whether other people are facing what we thought it could be an issue for v3 API as well as the strange and punctual 503 backend error a few people have reported. 

Thanks,

Luis

El 08/06/2012, a las 17:27, Nick <n...@google.com> escribió:

Hi,

If you are making too many concurrent connection to the API, then you will get this error below. What that means is that you need to slow down the number of requests you make to our service and retry the queries that generated the 403s at a later time.

Yes, our quota HAS changed from 2.3 -> 2.4, so for a small number of apps, some logic to control quota might need to change.

After you retry, and can consistently reproduce getting a 403 error, you can send me your profile id and we can take a look.

-Nick

On Friday, June 8, 2012 6:26:30 AM UTC-7, shumisha wrote:

Hi
Also experiencing this error all of a sudden from today (June 8) midday. This is with API V 2.4.
As per posts found elsewhere, I changed the per user/per IP allowance to 10.0/sec in the API console, as it is set to 1.0/sec by default, when the API project is created.

This didn't have any immediate effect, as I'm still receiving the error. I will allow some time though, as some time may be required for the setting change to propagate?

Rgds



Le vendredi 8 juin 2012 14:00:01 UTC+2, Anthony Bliss a écrit :

Also receiving this error as of 07 June 2012. No information or insight available :(

--
You received this message because you are subscribed to the Google Groups "GA Data Export API" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-analytics-data-export-api/-/uwZPY4BkUMoJ.

To post to this group, send email to google-analytics-data-export-a...@googlegroups.com.
To unsubscribe from this group, send email to google-analytics-data-export-api+unsubscribe@googlegroups.com.

[Anthony Bliss]

As stated above also receiving this error, no one has used the application in 12 hours and it is still not working.

I think our project ID is 238781502737

[Luis Pereira]

We think our project ID for web applications is 593523220381

2012/6/9 Anthony Bliss <abli...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/google-analytics-data-export-api/-/ad-jFpN_qRQJ.

To post to this group, send email to google-analytics...@googlegroups.com.
To unsubscribe from this group, send email to google-analytics-data-...@googlegroups.com.

[MT]

We've been receiving this same error occasionally for a few weeks ( https://groups.google.com/forum/?fromgroups#!topic/google-analytics-data-export-api/SHwujH2IxpI). Our queries are blocked despite not reaching the quotas, and the blocks aren't lifted as they should, can remain in place for hours.

[Nick]

Hi Anthony,

We looked into your account.

One of the GA profiles being accessed through your application is indeed hitting the 10 concurrent requests per profile. They are using both your application as well as a different application, and together, they get over 10 concurrent requests.

Based on usage patterns, it looks like this other application is eating up most of their quota.

Generally if you see this 403 error, we recommend your application should includes back off logic, and retry at a later time.

http://en.wikipedia.org/wiki/Exponential_backoff

-Nick

On Saturday, June 9, 2012 2:56:29 AM UTC-7, Anthony Bliss wrote:

As stated above also receiving this error, no one has used the application in 12 hours and it is still not working.

I think our project ID is 238781502737

On Friday, 8 June 2012 19:16:10 UTC+1, Nick wrote:

can you send me your project ID.

-Nick

On Friday, June 8, 2012 9:42:03 AM UTC-7, Luis wrote:

Well, the issue that we are facing is getting punctually this error while being far away from the threshold. We make no concurrent connection for a given profile and queries are enough distributed in time. That's why we raised this question, to check whether other people are facing what we thought it could be an issue for v3 API as well as the strange and punctual 503 backend error a few people have reported. 

Thanks,

Luis

El 08/06/2012, a las 17:27, Nick  escribió:

[Nick]

Hi Luis,

We looked into your account. It looks like you application did make over 10 concurrent connections on June 5th. Generally your project is not getting many errors, which is good. But we recommend that you include some sort of throttling mechanism so that you do not make of 10 concurrent requests.

If you do get this error again, we highly recommend you incorporate some sort of backoff logic so that you do not continue to makes queries to our API and get this error.

Good news is that it looks like a majority of your API requests return 200s.

-Nick

On Saturday, June 9, 2012 4:49:07 AM UTC-7, Luis wrote:

We think our project ID for web applications is 593523220381

2012/6/9 Anthony Bliss

As stated above also receiving this error, no one has used the application in 12 hours and it is still not working.

To post to this group, send email to google-analytics-data-export-ap...@googlegroups.com.

To unsubscribe from this group, send email to google-analytics-data-export-api+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-analytics-data-export-api?hl=en.

--
You received this message because you are subscribed to the Google Groups "GA Data Export API" group.

[Nick]

Hi Mikael,

Are you sure it's your application that is hitting this limit?

It could be another app that your client is using that is indeed causing issues for you. You might want to let your clients know that this API access has per profile limits, and their usage patterns will directly impact their experience using our API.

-Nick

[Windermere]

We are seeing this error also. Started happening today sometime around noon PST.
We have a Rails app, which pulls analytics data for custom presentation.

Updated the per-user limits to 10 requests/second, which had no effect.
Is it possible to check what is causing this to happen? Daily requests are well below 50K threshold.
Thanks,

[Nick]

Whats your project ID?

Per user IP / qps is different than maxing the concurrent requests, so changing the value in the developer console should not change this type of error.

-Nick

[Windermere]

Our profileId ga:605724.

[Nick]

Great I just checked.

It looks like you tried to make ~30 calls to our API within 2 seconds, and why you got that error. It then looks like you continued to make many requests for the following 2 hours.

So looks like our servers are responding as expected.

What you need to do is issue no more 10 queries at a time, then wait for the requests to fully complete, before issuing new queries. If you get an error, you need to implement an exponential back off.

wikipedia: http://en.wikipedia.org/wiki/Exponential_backoff

some docs: https://developers.google.com/google-apps/documents-list/#implementing_exponential_backoff

The last one is for a different Google API, but we'll probably copy it over into out Analytics docs since many people seem to be experiencing this issue.

-Nick

[Anthony Bliss]

Hi Nick,

Thank you for looking into that. Are you able to tell me the name of
the other application so I can find out if it is something my company
can look into or if we need to contact our client for more details.

> >>>https://groups.google.com/d/msg/google-analytics-data-export-api/-/uw...
> >>> .

> >>> To post to this group, send email to

> >>> google-analytics...@googlegroups.com.

> >>> To unsubscribe from this group, send email to

> >>> google-analytics-data-...@googlegroups.com.

[Windermere]

Nick, thanks you for checking.

We have a Rails app that requests a customized analytics report based on user's login info. To allow concurrent requests we have a few worker processes running, each with it's own instance of the Rails app. I believe that during heavy use too many concurrent requests are hitting GA API, hence we get a quota error. We have a few thousand users, all accessing their own slice of data under the same profile id, therefore quota error is almost guaranteed.

If it was an installed application, we could use user ip as a limiting factor, but in our case it's not an option.

In your opinion, where in this stack does the exponential backoff should be implemented?

[Nick]

I was a bit bust with Google I/O, but wanted to get back to you. It can get difficult to get the best performance for a server side app.

This API has 2 short term quotas.

10 concurrent requests per profile

10 qps per IP

Assuming each process is making queries to our API, you need to make sure that there aren't more than 10 processes querying for a single profile.

Within each process, you need to make sure that no more than 10 qps are happening. So you probably need to implement some sort of shared token bucket between processes, so that each API requests the rate limit.

Once you can guarantee there are less than 10 queries per profile and that you are running less than 10 qps overall, then you can make a request to our servers. If you do get an error code, then you again need to retry if necessary. This is where exponential backoff is helpful. But before retrying, you again need to make sure that you are obeying the 10 qps limit.

Looking through the solution, it might be easier to share memory using multiple threads vs processes

Hopefully this helps.

-Nick

[Max Werner]

Hi we get the same error
403 : Quota Error: profileId ga:6525815 has exceeded the daily request limit.

However, we don't make more than 10 qps, we don't make more than 50k per day, we don't have 10 concurrent requests so we are stumped as to why this happens. We even tried from a different IP to make sure the IP based limit doesn't apply.

Help please?