I have Windows Service that accesses Outlook items through Exchange Web Service (EWS). It often experiences concurrency issues.
Based on this doc, a maximum of 27 connections per user can be made concurrently for Exchange Online. I couldn't find documentation for the detailed throttling policies for Microsoft Graph.
Is there anyone know if I can make more concurrent connections in Graph API than EWS? Also, does Graph API show better performance in general than EWS such as response time?
This is documented in Microsoft Graph throttling guidance. There is also an in-depth look at Throttling patterns available.
Each endpoint throttles a little differently. For Exchange/Outlook endpoints it is 10,000 requests per app id, per user, within a 10 minute window.
The term "connections" doesn't really apply to an API like Microsoft Graph. As a REST-based API, it is fundamentally stateless. Each request is a self-contained transaction.
Related
I am trying to download/access on daily basis, all the emails exchanged over outlook365 by employees of an organization, who obviously uses outlook365. After download finishes I'll be running some background jobs on these emails.
I've option of doing this via EWS APIs, but the throttling policies are turning out to be pain and affecting the predictability of the system, because of throttling policies. Daily no of emails to be accessed could range from 0.1- 1 million or above.
I am exploring upcoming graph as of now, to see if it helps solving this. I also have another way out by routing these emails to lets say AWS SES or apache james and accessing/downloading from there, thus avoiding throttling all together. But I am trying to avoid additional servers in deployment as of now.
My question -
Has anybody experienced this issue and what was if at all any reliable way around while using outlook supported email APIs?
I've option of doing this via EWS APIs, but the throttling policies are turning out to be pain and affecting the predictability of the system, because of throttling policies. Daily no of emails to be accessed could range from 0.1- 1 million or above.
Inefficiency code is more likely the cause of the throttling then blaming the API (eg if your not using batching, requesting more properties then you need etc) so the first thing you should do make sure you optimize the code as all the client based API's are throttling similarly. 0.1- 1 million over the time-span of day isn't that many emails to process in my experience with EWS especially if your using Impersonation where throttling cost would be dispersed across the mailboxes your accessing.
We have a crawling engine that we are trialling on Google Kubernetes Engine.
It appears that we are severely network bound when it comes to making request outside the google network.
We have been in-touch with an architect at google, who though that perhaps there was some rate-limiting being applied inside the google data centre. He mentioned that I should raise a support ticket with Google to investigate. Raising a ticket involves subscribing to a support plan (which I am not ready to do until the network issues are addressed) [a bit of a catch-22].
Looking at the network documentation: https://cloud.google.com/network-tiers/?hl=en_US it seems that rates might be severely limited. I'm not sure that I'm reading this right, but are we saying 6Mbps network?
I'm reaching out to the community / Google to see is what we are seeing is expected, if there is any rate limiting and what options there are to increase raw throughput?
You can raise a ticket with Google using the public issue tracker free of charge. In this case, since it's possibly an issue on the Cloud side of things, raising a ticket in this manner will get a Google Engineer looking into this.
I am encountering some very long response times from Exchange Online called via the EWS Managed API 2.0 in C#. I suspect I am being throttled, but I cannot find anything that lets me prove this in the Admin portal for my O365 account. I have seen in some search results that using PowerShell you can see messages indicating "micro delays" have been applied, but I'm stuck in C#/EWS, so my question is: is there anything I can look at coming back in the responses to my EWS calls that can identify if these micro delays have been applied? BTW, response times are very close to the 100 second timeout time, which is killing my code.
Thx,
Paul
100 Seconds ins't a micro delay, micro-delays are milliseconds(capped at 500 ms) and are more aimed at delaying a large volume of requests. (eg if an app is going to may 100 sequential requests a microdelay would spread the load of those request out over a greater time by punishing the app more and more and that would lower the resource load on the server). One request taking 100 seconds to fulfill is probably more to do with the request itself. Eg overuse of search filters or overcomplex search etc which my also impact throttling or if your using batching each request withing the batch could have a micro-delay applied.
EWS doesn't return metrics of throttle usage (the new REST API does give a little more information back in this regards). What you need is access to the EWS logs which has that information. Each Exchange request the EWS Managed API makes has and Client Requestid to help correlate the request to log entry there more detail in https://msdn.microsoft.com/en-us/library/office/dn720380(v=exchg.150).aspx
I have read a lot, 1 but I still think I didn't find clear answers about the following questions:
1) A user of my web or mobile app uses an input in order to find Lat, Long of an address (I am using Javascript). Does this request represented by user's client IP or from my Server's IP?
I am asking because I want to ensure that this is a client side request in order to no overcome Google's 2,500 requests per IP.
2) Then, once I have the lat,long in my database I can draw the google map based on an array of lat, long which my user had store previously. Is this a request from my server's IP or user's IP?
Since the geocoding requests are going directly from the user's machine to Google, you are using what Google calls "client-side geocoding" which falls under slightly different licensing agreements than the 2,500/IP API limits.
Client-side geocoding through the browser is rate limited per map session, so the geocoding is distributed across all your users and scales with your userbase. Geocoding quotas and rate limits drive the strategies outlined in this article.
When running client-side geocode requests at periodic intervals, such as on a mobile app, your requests may be subject to blocking if all of your users are making requests at the same time (e.g. the same second of every minute). To avoid this, consider one of the following:
Use a caching strategy.
Introduce random intervals to your requests (jitter). Ensure requests are random across your entire userbase.
If developing for Android, use an inexact repeating alarm.
If developing for Android, select an appropriate location strategy.
In Google Maps API for Business, quotas are tied to client IDs, which provide much higher quotas. To learn more about Maps API for Business quotas and error handling, we recommend reviewing our article, Usage Limits for Google Maps API Web Services. If you're still running into quota limits using the Google Maps API for Business, file a support request here: http://www.google.com/enterprise/portal/.
I have seen several apps on the market that are allowing users to determine their current network connection speeds. How is this possible, and what might I use to be able to use this functionality? I am querying network types but I am not sure how to determine the current speed of the connections.
Besides the NetworkInformation class that gives you basic information about the connectivity (network available or not, wifi enabled or not) there is no API with the current SDK for determining network speed.
I guess the apps doing this simply create a web request to download some sample files hosted on their website and measure the time it takes, etc.