Rate limiting

[abuzuhri]

We need to work to have better version
https://github.com/abuzuhri/Amazon-SP-API-CSharp#usage-plans-and-rate-limits-in-the-selling-partner-api

[abuzuhri]

First version for rate limit ready for orders only
https://github.com/abuzuhri/Amazon-SP-API-CSharp/tree/UsagePlansAndRateLimit

[abuzuhri]

@gcuadrado Can you test Rate limiting and give feedback

[gcuadrado]

Hi, ok, I will try during this weekend!

[abuzuhri]

Now rate limit ready for Library we need to test before release

[gcuadrado]

I hope to have time to test it today, I will update you

[abuzuhri]

Good news

Alpha version now ready

https://www.nuget.org/packages/CSharpAmazonSpAPI/1.0.45.3-alpha

[abuzuhri]

After heavy testing for Time Rate , I notes if we wait only half of mention time the app will work perfect ,Its look like if you wait the mention rate they will give you one more Burst

@wizzardmr42
@gcuadrado
@Tilted-Software
@J-W-Chan
wizzardmr42 Can you help us on test , we need to arrive to the best solution for all

[gcuadrado]

So no changes for now, right?

[abuzuhri]

So no changes for now, right?

I mean for that part of divid by 2.

But now it's work perfect with new time limit you can download nuget and check it

[gcuadrado]

Oh sorry, I misunderstood you. Great! I am going to update the Nuget right now 👍

[abuzuhri]

Good , please check and give feedback

[ynaft]

I see you were testing for how much time it needs to throttle, as I did, and came to the conclusion that for requests with longer restore rates we lose a LOT of time by sleeping for the whole restore rate, I don't have a clear answer how the throttling works in the background, therefore I have no clear way to develop based on my findings, but it's a loss that we don't maximize to the possible speed.

See my exact findings here https://github.com/amzn/selling-partner-api-docs/issues/2279

[abuzuhri]

We are now fully support Rate limiting

[igoryan-k]

Hi @abuzuhri, thanks for providing the rate limiting. But it looks like I am still getting throttled on this particular function:
connection.CatalogItem.ListCatalogItemsAsync().
I am getting "You exceeded your quota for the requested resource." error after about 30 requests. I tried to rate limit myself to 1 request per second and still getting it even though the rate is supposed to be 5 times per second. Any ideas?

It's a little hard to debug since the rate limit header is not exposed by the library.

[rcalv002]

[abuzuhri]

Getting this error mean you have call get order many times before the first call finished .

I will to do small change and check with you later if that solve the problem

[igoryan-k]

In my case I used a single connection and do calls to the CatalogItem service from a single thread. I did a single call at once and waited for completion before making another call. But I was still getting the rate limiting message.
The same function was making calls to ProductPricing.GetItemOffers at the same rate and there was no error.

[wizzardmr42]

I don't think this approach to rate limiting will work for most use cases. I've disabled it and I'm dealing with rate limiting by catching when there is a rate limit error and retrying after a wait period. I have a scheduled task and a website which both use it and no way to share the limit data, plus the scheduled task loses the data when it finishes and can sometimes restart before the limits have been fully refreshed. I also found it a problem that it delays when it isn't necessary - in some cases I could make all of the calls in a burst without hitting the limit, but it still waited.

[rcalv002]

@abuzuhri Were you able to check this?

[rcalv002]

Yes this sounds correct, its a one singleton and as far as i can see when you do calls to the order service it goes like this. and so it overrides lists before stuff is done maybe? of course there are several calls coming into the api at once which would trigger individual calls out to amazon via the singleton..

Thanks for checking

[abuzuhri]

#178

[RenzoF]

Hi @abuzuhri The rate limiter seems to be working fine for me thanks for doing that.
The only issue I have is that I use multiple "workers/threads" that handle a queue of reports and therefore the current usage is wrong.
It would be nice to abstract that so that the value could be held in memory (as it does now) but we could also use any other type of storage, like a database, thoughts?

[wizzardmr42]

@RenzoF That's what I am doing. It feels pretty messy though - would be better if there was a more integrated solution, especially as I don't like having to deal with it on every call.

[RenzoF]

@RenzoF That's what I am doing. It feels pretty messy though - would be better if there was a more integrated solution, especially as I don't like having to deal with it on every call.

Agreed, what do you suggest the best approach would be? Something that works for everyone and compatible with the way that currently works

[wizzardmr42]

@RenzoF I'd design an interface that has functions on that are called before each API call and when there is a rate limit error and allow for anything that implements that interface to be used. It will need a little thought. Eg. I would pass in the number of retries so far on this call and the date/time it was initially requested and then have a way to return whether to retry or abort. I'd also put in properties to control behaviour for things like throwing exceptions if it signals an abort.

[RenzoF]

We are thinking the same 👍🏼, @abuzuhri would you agree with this approach?

[abuzuhri]

It’s totally ok if the solution not affect other of course it’s ok .

i wi look to IDistributedCache and think on that

[pellet8]

How to suppress the Rate Limit message in a console application?