I need to run a report which needs to extract information from a WCF service which is running as an Azure Web App. Unfortunately, there are about 6000 requests I need to run and they MUST be run individually.
When I throw the entire book at the service, I get
ASP.NET rejected this request because the queue limit was exceeded.
I can't find any information which says what the Request Queue Limit is per pricing tier.
Does anyone know what the limits are?
This is not an Azure limit, the queue length is IIS/CPU/Memory bound. See this ServerFault answer for a brief explanation. You should consider having your app queue/throttle the requests with a mechanism like Azure queues.
Related
I am running WSO2 APIM 2.1.0 , I am setting Tier Availability to Unlimited . Still getting 429 too many request error while doing load testing.
You need to make changes as per given in document.
If you have custom throttling policies, it has some issues with WSO2-2.1.0. Better to get upgraded to wso2-2.6.0.
There are many possible reasons for this kind of issue.
Are you trying throttling scenario on unauthenticated API? When you are going to add a new Subscription level throttling tier in the admin portal, you could see the existing list of subscription tiers in the Subscription Tier List. In this list, you will find a tier named Unauthenticated which has a request quota of 500. This is a subscription tier that automatically applied when the authentication type of your resources is 'None'. That is used when you can invoke APIs without tokens. And this tier is not visible in the Throttling tier list of the application.
Please check the Traffic Manager node connectivity.
Check whether any other throttling tier like application, API, resource level are published with the API.
Check the unit time while you are getting the throttled out response. Invoke the API after unit time getting passed. If the unit time is a larger value, then you should restart the server and try again.
Check the throttling configurations in the gateway, traffic manager, and the publisher.
I'm using the Java client library's MetricServiceClient for getting StackDriver timeseries. I am authenticating using a user oauth token (this user has access to multiple projects), but there seems to be some kind of global quota across multiple projects because when I fetch only one or two projects at a time I have no throttling, but when I fetch four or five different projects at a time, I start getting throttled with errors like the following:
io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: Insufficient tokens for quota 'DefaultGroup' and limit 'USER-100s' of service 'monitoring.googleapis.com' for consumer 'project_number:764086051850'.
I have confirmed this by alternating which projects are being fetched so that I can say it is not any single project -- they all start to get rate limited. Another strange thing is, that project_number in the error message doesn't correspond to any project I am fetching, or even have access to -- it is meaningless to me.
This appears to be the quota for # of requests per 100 seconds, but I have that set to 10,000 on all projects and I'm not doing nearly that many requests, as the quota historical chart in the web console confirms.
Is there really some global quota that applies across multiple projects and if so, is there some way to work around it? It is much simpler to me to have a single user with access to multiple projects instead of having to make service account tokens for them all.
The token quota you're hitting is for users using Application Default Credentials (which uses a shared gcloud project for billing), while it exists to get users up and run quickly but it's not recommended for actual production use. Therefore using a proper service account bound to the user's project is highly recommended and the solution to the issue.
After some time playing with the Google Assistant SDK, I start getting this error:
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with
(StatusCode.RESOURCE_EXHAUSTED, Insufficient tokens for quota
'ConverseGroup' and limit 'DailyLimit' of service
'embeddedassistant.googleapis.com' for consumer 'project_number:
<REDACTED>'.)>
What does this mean and how can I resolve this?
The Google Assistant SDK is free to use but has some daily usage limits per account, to prevent abusive use of the API (e.g. non personal or non developmental use, as allowed by the terms of service).
This trace is the error you get when hitting that limit.
The most immediate solution to this problem, is to try again the next day. If you need more requests for your project, you can also reach out to this form to request more quota explaining what your project is about and why you need it.
I have a client-server web application - the client is HTML/JS and the server is ASP.Net. web application hosted by Azure Web Role
In this application the client can save a document on the server by calling a web service method on the server side.
After calling the saving method, the client might save the document again while the server processes his previous save request. In this case I want the newly initiated saving to be queued until the previous saving operation is completed.
If I had a single web role instance, it would be easy for me to implement this by thread synchronization, but since the client request might be handled by different web role instances, the synchronization is problematic.
My question is - how can I implement such synchronization mechanism, or is there a better way to get the same result, that I'm not aware of.
Thanks.
I would consider combination of storage or service bus queues to queue up the requests to process the documents AND using BLOB leases to mark the work as in progress.
Queuing would be important since the requests might be delayed in processing if there is a previous request for the same job that's on going.
BLOB Leasing is a way to put a centralized lock in storage. Once you start processing of a request, you can put a blob with a lease on it and release the lease once you're done. Requests for the same work would check first if the lease is available before kicking off. Otherwise, they could just wait. More info on leases here: http://blog.smarx.com/posts/leasing-windows-azure-blobs-using-the-storage-client-library
Have you looked into using the Windows Azure Cache - Co-Located on your roles?
This is a shared caching layer that can use excess memory on your roles (Or have it's own worker role if your web roles are already close to capacity) to create a key / value store which can be accessed by any role on the same deployment.
You could use the cache to store a value indicating a document is currently being processed and block it until the document has finished uploaded. As it is a shared caching layer the value will be persisted across your instances (Though the cache will not persist during an upgrade deployment).
Here's a good introductary article to using Caching in Azure with configuration examples and sample code.
Recently I was developing an application using Linkedin people-search API. Documentation says that a developer registration has 1 lac API calls per day, but when I have registered this API, and ran a python script, after some 300 calls it says throttle limit exceeds.
Did anyone face such kind of issue using Linkedin API, comments are appreciated.
Thanks in advance.
It's been a while but the stats suggest people still look at this and I'm experimenting with the LinkedIn API and can provide some more detail.
The typical throttles are stated as both a max (e.g. 100K) and a per-user-token number (e.g. 500). Those numbers together mean you can get up to a maximum of 100,000 calls per day to the API but even as a developer a single user token means a maximum of 500 per day.
I ran into this, and after setting up a barebones app and getting some users I can confirm a daily throttle of several thousands of API calls. [Deleted discussion of what was probably, upon further consideration, an accidental back door in the LinkedIn API.]
As per the Throttle Limits published by LinkedIn:
LinkedIn API keys are throttled by default. The throttles are designed
to ensure maximum performance for all developers and to protect the
user experience of all users on LinkedIn.
There are three types of throttles applied to all API keys:
Application throttles: These throttles limit the number of each API call your application can make using its API key.
User throttles: These throttles limit the number of calls for any individual user of your application. User-level throttles serve
several purposes, but in general are implemented where there is a
significant potential impact to the user experience for LinkedIn
users.
Developer throttles: For people listed as developers on their API keys, they will see user throttles that are approximately four times
higher than the user throttles for most calls. This gives you extra
capacity to build and test your application. Be aware that the
developer throttles give you higher throttle limits as a developer of
your application. But your users will experience the User throttle
limits, which are lower. Take care to make sure that your application
functions correctly with the User throttle limits, not just for the
throttle limits for your usage as a developer.
Note: To view current API usage of your application and to ensure you haven't hit any throttle limits, visit
https://www.linkedin.com/developer/apps and click on "Usage & Limits".
The throttle limit for individual users of People Search is 100, with 400 being the limit for the person that is associated with the Application as the developer:
https://developer.linkedin.com/documents/throttle-limits
When you run into a limit, view the api usage for the application on the application page to see which throttle you are hitting.