Note: This question is about something that I do not understand in the documentation here:
https://developers.google.com/gmail/api/v1/reference/quota#concurrent_requests
Concurrent Requests
The Gmail API enforces a per-user concurrent request limit (in
addition to the per-user rate limit). This limit is shared by all
Gmail API clients accessing a given user and ensures that no API
client is overloading a Gmail user mailbox or their backend server.
enforces a per-user concurrent request limit (in addition to the per-user rate limit).
I do not find what is the 'per-user concurrent request' anywhere in their documentation. Whereas the per-user rate limit is found at the top in the same page.
https://developers.google.com/gmail/api/v1/reference/quota#top_of_page
The Gmail API enforces a per-user concurrent request limit (in addition to the per-user rate limit). This limit is shared by all Gmail API clients accessing a given user and ensures that no API client is overloading a Gmail user mailbox or their backend server.
The confusion here is the difference between per-user concurrent request limit and per-user rate limit
Lets say I make an app that lets users read from their Gmail account. I am going to be limited by the number of request each user can make though MY app the limit is per-user rate limit
Now lets say the user installs your app which also allows them to access their Gmail account. You are also limited to how fast the user can access the api via the per-user rate limit.
However both of our APPs and the gmail and inbox apps are are all running with the same per-user concurrent request limit concurrent meaning across all of the apps the user is using.
the per-user concurrent request limit is probably there to ensure that a developer doesn't create a number of different projects and rip data using all of them.
To my knowledge per-user concurrent request limit is not documented its a stealth limit and i have never seen anyone who has been able to nail down exactly what the numbers are for the concurrent limits in Google APIs. With the exception of the Google Analytics API which is 10000 not including the google analytics website and the official mobile apps
Example:
per-user rate limit
User number one logs in and lists all of his emails he has 10 user gets no error.
User number two logs in, he has 1000 emails and your application tries
to select them all out in 1 second. You are going to get a rate limit error for this user. You are flooding google.
However apps by other developers will be able to access the user inbox via the API
per-user concurrent
user number one is only running your application. logs in and lists all of his emails he has 10 user gets no error.
User number two is running your application and 20 other applications by other developers. Tries lists all of his emails assuming he has done this on all the applications at the same time he may end up getting an error.
These errors are user based due to the name Per-user in the name of the limit.
Example 2:
Lets look at the Google analytics API because i know the hard numbers for this api.
A user using your app can max make 100 requests over 90 seconds. (User-app based)
An application can make max 50000 requests a day. (App Based)
An all Applications can max make 10000 requests a day against a view (concurrent app based)
Related
After 40 calls to users.settings.filters.create I start to receive User-rate limit errors. All future filters.create calls then fail for the next (approx) 24hrs. Specific error message below.
HTTP 429
"User-rate limit exceeded. Retry after 2021-05-19T07:24:15.104Z
(Forwarding rules)] Location[ - ] Reason[rateLimitExceeded]
Domain[global]"
I have a 5-second delay between each call, so well under the published daily usage and per-user rate limits. I calculate the API allows 250 / 5 = 50 calls per second.
https://developers.google.com/gmail/api/reference/quota
We are using Google Workspace Legacy edition, the project OAuth consent is set for Internal use and the project is not verified (not a requirement for Internal).
Is there an obvious reason that 40 consecutive filters.create calls spread over 200 seconds would trigger a User-rate limit in these circumstances?
Limitations for unverified apps are across the board. The fact that your app is for internal use only doesn't matter you must still abide by the unverified app restrictions.
If you want to be able to send more then that you will need to apply for verification.
Because your app is for workspace account and internal use it should be easer for you to verify it.
When using the google-apis People API I encountered a "Sync Quota Exceeded" error while executing requests to maintain an updated state of my contact list. The request rate was once every 5 seconds. I think I left it on overnight.
I remember reading (Though I can't find the source anymore in either Calendar or People) that requests with sync tokens have their own quota. Where is that quota? Can I request that it be raised?
If I go to all my Quotas in IAM and Admin I can see my People API quotas
And if I go to the People API Usage, I can see quotas, but not their usage. I also see no mention of the sync quota. Where can I find information about the Sync Quota?
People API Critical read requests per minute per user
People API Critical write requests per minute per user
People API Write requests per minute per user
People API Read requests per minute per user
the quota can be found in https://console.developers.google.com -> APIs & Services -> Library -> search People API -> click to Manage -> Quotas.
We have a system to simulate 5000 users accessing the system concurrently in the 30-minute time span. It uses Microsoft online login accounts and authenticated users are redirected to the system.
Note: We have a limited number of user accounts for the testing. (20 user account)
User logins throughput = 5000/(30*60) = 2.78 user logins/second
Considering the limited number of user account following is planned
Use 20 user accounts to simulate 3-5 logins/second for a period of 30 minutes with throughput controlling plugins
Simulate active user in the system with direct API calls
Questions
Is this a correct way to handle the required throughput with a limited number of user accounts?
What are the other options available
In general the best practice is to have 1 to 1 mapping of JMeter thread (virtual user) to a real user. Depending on how does your application treat new logins it might not show the full picture, especially if some background activities are being triggered for each new login. Moreover, libraries, databases, operating systems, application servers, and other middleware tend to cache requests results so 1 user making 5000 calls is not the same as 5000 users making 5000 calls.
Well-behaved load test needs to simulate real usage of the website (or application or service) as close as possible so if you're testing a website that communicates with the backend using API - it's only a part of the traffic from the browser to the destination, in reality, things could be much more complicated like sending relevant headers, downloading embedded resources (remember about client-side caching as well), executing AJAX calls (when different API calls are being invoked by the same user in parallel) and so on. See How to make JMeter behave more like a real browser article for more details.
So recommendations are:
generate another 4980 test users
make sure that each virtual user's network footprint exactly matches the real browser (or other application which you're simulating) one
Since today (november 20 2018) we get error responses from Google's RuntimeConfig API:
Our systems have detected unusual traffic from your computer network. This page checks to see if it's really you sending the requests, and not a robot...
(check this link for complete HTML error)
We retrieve variables from Google's RuntimeConfig using the API in our code. We do quite a few request, but not more than before:
A developer starts his server locally, which retrieves all the needed variables (+- 30 everytime you start).
Requesting RuntimeConfig variables via GCloud results in the same HTML error:
gcloud beta runtime-config configs variables get-value databaseHost --config-name database --project=your-test-environment
Other gcloud api requests work (projects describe, gsutil, etc).
How can I verify if I violated any terms? I can only find a usage limit in GCloud Console of 6000 calls per minute.
You can find the quotas for Runtime Configurator and how much of those you are using in the Cloud Console under IAM & Admin. In the Quotas section you can filter on Service = Cloud Runtime Configuration API and you should see all the quotas and how close to those you are for this API. There are 4 quotas that may affect you (docs here):
1200 Queries Per Minute (QPM) for delete, create, and update requests
600 QPM for watch requests
6000 QPM for get and list requests.
4MB of data per project, which consists of all data written to the Runtime Configurator service and accompanying metadata.
We had the exact same issue on November 20th when a large amount of our preemptibles were reallocated at the same time.
Our startup-scripts make use of the gcloud beta runtime-config...-commands and they all responded with 503.
These commands responded correctly again after a few hours.
We have had a support-ticket with Google and there was a problem with their internal quota mechanisms at the time which since is fixed so the issue is resolved.
any easy to use utility/tool/profiler/benchmark that able to test what is the maximum users a web application able to support by analyzing session size , cpu speed, memory size..etc and 'PREDICT' when server is overpacked/overloaded?
Apache JMeter is a simple-to-use system that fires requests to your web server. You can try different numbers of users (i.e. sessions) with different numbers or types of requests. You could try increasing the number of users until the latency/speed of your system is unsatisfactorily slow.