Request throttling about livesdk-for-windows HOT 6 CLOSED

This is a no trivial problem for us on the OneDrive team. With the creation of the Live Connect APIs there were certain design goals that shaped our client usage patterns especially around scalability, which is why there are limits like you are seeing when your requests are throttled. While adding features in the SDK to help support high-performance scenarios could help ease the burden on developers, it wouldn't change the constraints that are limiting requests to the service.

We have been working diligently to free developers from these limitations with the OneDrive API. It takes something to grok and then transition to other technologies and I appreciate this is not trival. We are taking this route to create the future of the OneDrive service that will have full parity with everything the OneDrive sync client does, as well as the website available to you as well since everything will use a uniform API.

With all that said you had some specific questions that I don't want to leave you hanging on, the OneDrive apis that LiveConnect exposes are throttled into 2 buckets, read-only operations (GETs)
and write operations (POST, PUT, etc). The bucket size for reads is much larger than writes and so if you want to make sure that you aren't wasting cycles while performing write operations against the service, use two separate requests queues for reads and writes and you should be better able to detect where delays should be applied.

from livesdk-for-windows.

Thank you so much for your response. So if I understand you correctly, Live SDK is kinda "legacy" / "for compatibility" and the OneDrive API is the place to go for new projects? I have been looking into the OneDrive SDK, but that project seems to be in very early stage of development, with virtually zero (human) comments, and randomly commented-out code. Live SDK on the other hand looks much more mature so I am a bit confused.

I realize that the suggested request coalescing feature would definitely not change any constraints to the service (which wasn't it's goal anyway), but it would work around them in such a way that these constraints would no longer be a limit for many more benign applications.

The request throttling into 2 buckets (read; write) apply to the OneDrive API as well? Or is that limited to the Live Connect API?

Furthermore, could you please help me to make sense of how the throttling actually works? As per OP, I have dozens of outstanding requests at the server, which processes them one at a time. At some point, it starts throttling the requests in its queue, so all the subsequent requests invoke some kind of incremental throttling - which however seems to behave very strangely. My app gives me the following output (first value means how long the client should wait before next request, second value is local timestamp of when I received this server response):

Waiting requested: 00:00:04 (19:41:27)
Waiting requested: 00:00:22 (19:41:28)
Waiting requested: 00:00:39 (19:41:28)
Waiting requested: 00:00:57 (19:41:29)
Waiting requested: 00:01:14 (19:41:29)
Waiting requested: 00:01:32 (19:41:30)
Waiting requested: 00:01:49 (19:41:30)
Waiting requested: 00:02:07 (19:41:30)
Waiting requested: 00:02:25 (19:41:31)
Waiting requested: 00:02:43 (19:41:31)
Waiting requested: 00:03:01 (19:41:31)
Waiting requested: 00:03:18 (19:41:31)
Waiting requested: 00:03:36 (19:41:31)
Waiting requested: 00:03:54 (19:41:32)
Waiting requested: 00:04:12 (19:41:32)
Waiting requested: 00:04:29 (19:41:32)
Waiting requested: 00:04:47 (19:41:32)
Waiting requested: 00:05:05 (19:41:33)
Waiting requested: 00:05:22 (19:41:33)
Waiting requested: 00:00:04 (19:41:33)
Waiting requested: 00:00:22 (19:41:34)
Waiting requested: 00:00:04 (19:41:34)
Waiting requested: 00:00:22 (19:41:34)
Waiting requested: 00:00:21 (19:41:34)
Waiting requested: 00:00:21 (19:41:35)
Waiting requested: 00:00:20 (19:41:35)
Waiting requested: 00:00:20 (19:41:36)
Waiting requested: 00:00:19 (19:41:36)
Waiting requested: 00:04:17 (19:42:57)
Waiting requested: 00:04:34 (19:42:57)
Waiting requested: 00:04:52 (19:42:58)
Waiting requested: 00:05:09 (19:42:58)
Waiting requested: 00:00:09 (19:42:59)
Waiting requested: 00:00:09 (19:42:59)

All requests were of the same type. So as you can see, the server is punishing my client, increasing the wait time as it finally begins to deal with the backlog of requests in it's queue (at which point my client has no way of actually stopping this incremental punishment). But then suddenly the punishment seems to randomly start floating around "20 seconds", then jump up again and drop yet again... My client stops sending any requests as soon as it sees the first throttling response, so all these throttling responses are received as the server deals with the backlog queue. How am I supposed to react to his? Should I take average of all the wait times? Or the longest one? I am not sure what the server expects...

from livesdk-for-windows.

RE: OneDrive API - the project you linked to is sample code to show an example of how to use the API. We have not yet delivered an SDK project that works with OneDrive API and are working on that. Live SDK is a more mature product in that it's existed for years, where OneDrive API has just launched in February, but it is where all of our team's attention is focused right now.

from livesdk-for-windows.

Always wait the max time that you've seen from the service. There is some variability depending on which one of our many servers you see for any given request and the refresh state of the throttle information (hence the slightly confusing times).

The OneDrive API limits are an order of magnitude higher than the LiveConnect APIs. An application that flirts with these limits on LiveConnect will not ever encounter them on OneDrive API.

from livesdk-for-windows.

Thank you guys so much, it seems OneDrive API is the way to go for my particular project.

Since the Live Connect API throttles requests into 2 buckets (read; write), is the same throttling algorithm used in the OneDrive API backend as well? I understand that OneDrive API does have much more generous limits, but it's better to be ready. :-)

from livesdk-for-windows.

With the OneDrive API I would advise you manage all of your requests to the service through a single system that can detect the throttling requirements and keep all of your requests backed off until after the cool off period has expired.

The internal system that OneDrive uses to manage throttling will change over time so trying to design for its specific design right now would be less than ideal when changes are introduced.

from livesdk-for-windows.