I have a list containing Amazon products (ASINS). I want to update the buybox price in my list like every 5 hours. I am an registered Amazon seller so I do have access to the Selling Partner API - Amazon-Services-API. But the issue here is the rate limit. It is only 0.5 requests per second.
I have like 500k products in my list, it would take like multiple days with a rate limit of 0.5 requests per second.
There are serveral tools like scanunlimited or analyzer.tools which are able to obtain the current buybox price of a product way faster. Where are they getting their live data from? Am I missing out on some API?
Does anyone have an idea, how I can gather the data more quickly then 0.5 requests per seconds?
Kind regards
Related
I am calculating the operation costs for a platform we want to develop for a client in AWS. The platform is an online course solution where users can subscribe and access different multimedia contents.
My initial thought was to store the videos in an S3 bucket and simply "feed" them to my back end solution so that the front end can access and show them.
My problem is that when doing the cost estimate I am getting huge cost estimates in Outbound Data Transfer. I don't really know how much traffic the client is expecting so I estimated traffic the following way (this platform is gonna be supported by the state so it will have some traffic):
20MB for every minute of video:
2 hours per week for every user
200 users per month
20MB/m * 60 m/h * 2h/week * 4weeks * 200 = 1.92 TB
This, at 0.09 USD / GB gives me 184.23 USD per month...
I don't know if I am not designing a well made solution, if my estimate is wrong... but I find this to be very expensive. Adding other costs this means I have to pay nearly 2 USDs per user. If someone finds a way to reduce costs please let me know!
Thank you
Total number of simultaneous users - 200,
Test duration - 2 hours
Load Profile:
Script 1: Browse Catalogue -> 10 steps > 2000 expected rate of business processes/hour > 100 users
Script 2: Search Product -> 6 steps > 1400 expected rate of business processes/hour > 60 users
Script 3: Buy Product -> 12 steps > 600 expected rate of business processes/hour > 40 users
With only this data, how to find out the average user concurrency (per sec)?
Concurrency is about collision in a give time frame. Simultaneity is about same request, same time.
Concurrency over the course of an hour is different for a second. For each of your steps, it is also impossible to understand how many requests are made to the servers under test and what resources are in use. As an example, it is not uncommon for public facing web pages to be made up of hundreds of individual requested elements.
Concurrency on which tier? Web? If web, then I can distort that highly with a cache model, a cache appliance (Varnish), a CDN. App Server? If my requests are all under 100ms apiece to be satisfied I might never have a concurrency in a second above but a few. Database server? If queries are the same across users then some of that might be distorted by caching of the results, either living in the query cache or a front end cache which takes the load off of the DB.
Run your test, report on it. That will be the easiest way.
You could refer to this web, it describe Performance Test Workload Modeling, could help you to calculate the Percent Load Distribution.
Then you can measure the manual operation time of each transaction and average time of each script. When you have Percent Load Distribution and average time, you could calculate the minimum amount of virtual user.
I am using for 4 dataset group for example:-
Movies
Mobile
Laptops
AC
And in each datasetGroup, we have 3 datasets with name Users, Item and Item_User_INTERACTIONS
And we also have one solution and Campaigns for each dataset group.
I am also sending the real-time event to AWS Personalize using API (putEvent)
The above things cost me about 100USD in two days and showing 498 TPS hours used and I am unable to find the real reason for this much cost.
Or does AWS Personalize simply cost this much?
As your billing tells you, you have used 498 TPS hours, let's calculate if it should be $100.
According to official Amazon Personalize pricing:
https://aws.amazon.com/personalize/pricing/
For first 20K TPS-hour per month you have to pay $0.20 per TPS-hour.
You have used 498 TPS hours in two days, it gives us:
$0.2 * 498 = $99.6 in total.
The answer is: yes, it's expensive.
Another question is:
How TPS usage is calculated?
They charge you for each TPS that is currently reserved. So if you have a campaign with 1 TPS and it's created for 24 hours, then you will be charged for 24[h] x 1[TPS] = 24 TPS hours = $4.8.
The problem is, that $0.2 doesn't look expensive, but if you multiply it by hours, it becomes very expensive.
For testing purposes you should always set TPS to 1, since you cannot set it to 0. 1 TPS allows you to get 3600 recommendations per hour, which is a lot anyways.
The reason for such high price is because of created Campaign which exists and therefore running (this part of AWS Personalize uses more resources than uploading data to s3/creating a model. It is based on TPS-hour per month metric)
E.g. suppose you uploaded a dataset with 100000 rows
Training will cost you about $0.24*2=0.5$ (assuming training took 2h)
Uploading to s3 and dataset - almost free
A created campaign which allows 1 request per second will cost $0.2*24*30=144$ per month
If in the production environment you will set a campaign to support 20 requests per second, it will be 2880$ per month.
So definitely, if these are your first steps with AWS Personalize, create campaigns only that support 1 request per second and verify that you delete unused resources on time.
In case of the SIMS recipe, there is also another way which might save you some money. Try to check how much it will cost for you just to retrain the model every 3d, for example, and to create batch recommendations for your items. Using this strategy we are spending now only 50$ per month per e-Shop instead of 1000$ per month.
Find more data in AWS docs
Let's say I'm creating a PWA (Progressive Web App) where products can be added by users.
Prices of these products are variable from 0,01 EUR to 1,00 EUR.
I'm using Stripe for payments.
The Stripe Order object do not support dynamic price, passed on the fly, without any reference (kind of foreign key).
To accept the Order, Stripe needs a reference to a SKU.
This SKU will be, in my case, a variation of the price, on the product.
It means that, to cover all variations, I need 100 SKUs, from 1 (0.01 EUR) to 100 (1,00 EUR).
So, for each product created in Stripe, I need to create 100 SKUs in Stripe.
I tried to insert a test dataset of 200 products, which means (200 products + (200 x 100 SKUs)) = 20200 requests.
I got a surprising "Request rate limit exceeded" error from Stripe.
Less than half of records where created... :(
That "Request rate limit exceeded" is the core of the problem.
Right now, the insertion process is the following (x 200):
Create product in Firestore.
Firebase cloud function listener :
OMG new product inserted in Firestore. Ok let's :
Import official nodejs Stripe & Algolia libraries
Create product in Stripe to make it billable
Create the 100 SKU related to the product in Stripe, with Promise.all (This is where, at some point, I end up with a rate limit error, because my concurrent cloud functions instances are using the same Stripe key, which means the same Stripe account)
Create product in Algolia to make it searchable
I need solutions to counter this Stripe API rate limit error.
I have several solutions in mind :
Solution 1 :
Be able to increase Stripe rate API limit for a given amount of time.
Not sure this is possible.
Solution 2 :
Be able to use differents Stripe keys, then rotate over them, to perform admin stuff, such inserting multiple products/SKUs in Stripe.
Ultimately on production, be able to create programmatically 1 Stripe key per user, so each user would have its own limit.
Not sure this is possible.
Solution 3 :
Slow down insertion process in javascript.
Don't know how to perform that.
Besides, Cloud functions have a budget/limit of 60 seconds for javascript execution. So I can't delay too much.
Solution 4 :
Delay work using Pub/Sub (?), or Firestore Triggers
For example, having an integer in Firestore, that each function call increments, and same function listen the write to re-increment he number, etc, etc, etc, until the number equals 100 for the 100th SKU. That solution would sequentialize the 100 SKUs writes in Stripe.
Not sure this will really slow down enough the work to be under the API rate limit. In addition, such a solution would cost lots of money : 100+ Firestore writes, and 100+ functions calls to perform these writes, for only one product, which means 20000+/20000+ for the 200 products. That would be expensive.
Solution 5 :
Perform Just-In-Time insertions, when user pays.
The server side algorithm, after a Payment Request API call, might look like this :
Create order in Stripe
If error 'No such sku...' catched {
For each SKU { // Ideally filter here SKUs to create (only those in error)
If price not between 1 and 100 {
continue // Bad price, not legit
}
Create SKU in Stripe
If error 'Already exists' {
continue // no creation needed for that SKU
}
If error 'No such product...' catched {
If productId does not exists in Firestore {
continue // Bad productId, not legit
}
Create product in Stripe
}
Create SKU in Stripe
}
}
Create order in Stripe
This last solution could do the job.
But it might comes with some delay for the user when it executes payment, which could increase stress. Plus it might increase Stripe calls during the business hours. Many purchases in same time could lead to a Stripe API rate limit error, especially with well furnished carts (let's say an average of 30 products in the cart, so in worst case 30+ HTTPS calls during payment, times 1000 users = 30000 calls => Stripe error). That problem might decrease over time for a given product, because once a SKU is created it is created definitively. Still, as there would be new products, so products with zero SKU at creation, every day, the problem remains.
What do you think ?
Do you have any other ideas ?
Solution 3 and Solution 5 with some tweaks will work best.
Solution 3: You can limit number of concurrent requests to Stripe using async module's forEachLimit or queue.
Solution 5 : Just in time insertions is also a good option as it won't put much load on Stripe server at same time. Regarding your concern of getting the same error during business hour, it will a very rare case as Stripe APIs are built to perform very well. But if you still have doubt regarding this what you can do is to have a Background process for adding SKUs during non-business hours, which will keep on creating SKUs for you without encountering Stripe API rate limit error.
Solution 6 (Modified Solution 5): Have just in time insertions but also create an extra API request to your server whenever a product is entered in the cart which will then check if the SKU exist in Stripe and if not then create it in the background before cart payment happens.
Solution 6 :
Same idea (JIT), but moving SKU creation from payment time to product selection time. Each time a product is selected, try to create the product and its current SKU (price variation) in Stripe. This way, Stripe calls should be more distributed in the time. Or maybe it will ends with more API calls, as we select products more often than we pay, because users can select & unselect products, so they might end with more products selected during their journey than the sum of products finally being paid in the cart ?
Solution 7 :
Same idea (JIT), but with SKU cached in Algolia or Firebase, so I can perform "does this SKU exist ?" calls without querying Stripe, which should reduces Stripe calls if the existence test is performed before the create call (we do not call Stripe.skus.create() blindly). The drawback is, that Firebase and Algolia are exposed in Front so the SKUs and prices will be too, and this is a potential source of threat, so another index, dedicated and only known by the server, has to be used.
I was given an Amazon awsAccessKeyId and awsSecretKey,
also our company has affiliated with Amazon, we get a Associate Tag.
And I was told we may get higher API limits, because we are affiliated.
But I don't have any detailed info about the API limits,
I want to know how many calls i can make in a second
Is there any way I could check our API Key status?
The call i use will be check product info like:
Service=AWSECommerceService
&Operation=ItemLookup&ItemId=[ID]
&IdType=ASIN
.....
When you exceed the requests limit, Amazon Product Advertising API sends a (possibly gzipped) response with 503 status code. Example response for ItemLookup query:
<?xml version="1.0"?>
<ItemLookupErrorResponse xmlns="http://ecs.amazonaws.com/doc/2013-08-01/">
<Error>
<Code>RequestThrottled</Code>
<Message>AWS Access Key ID: YOUR-AWS-ACCESS-KEY-ID. You are submitting requests too quickly. Please retry your requests at a slower rate.</Message>
</Error>
<RequestId>fabebd87-54a2-44ec-b547-deb5feee900a</RequestId>
</ItemLookupErrorResponse>
The rules have changed since #at0mzk's answer.
You have to make sales to use the API. The limits are set by sales in the last 30 days.
Effective 23-Jan-2019, the usage limit for each account is calculated based on revenue performance attributed to calls (also called requests) to the Product Advertising API (PA API) during your account’s latest 30-day trailing period.
Each account used for Product Advertising API is allowed an initial usage limit up to a maximum of 1 request per second and a cumulative daily maximum of 8640 requests per day (TPD) for the first 30-day period after your account has been approved. Following that period, your PA API usage limit will solely be based on your shipped item revenue. Your account will earn a usage limit of 1 TPD for every 5 cents or 1 TPS (up to a maximum of 10 TPS) for every $4320 of shipped item revenue generated via the use of Product Advertising API for shipments in the previous 30-day period.
Docs
Apparently there's not way of checking exactly what those limits are and they will change based on the performance of your account.
It seems that the minimum rate limits are:
1 request per second
8640 requests per day
Those limits will increase if your account has a good performance (as in shipped items revenue) using the API links.
From: Amazon Product API - Troubleshooting
API Rates
Curious to know how we provision API call rates for Product Advertising API 5.0? First, some definitions:
TPS – Transactions per second, refers to the maximum number of API calls you can make in one second. Each API call counts as one transaction. For example, if you send 10 ASINs in the request parameter of a GetItems() call, it counts as a single transaction.
TPD – Transactions per day, refers to the maximum number of API calls you can make in one day. If Associate has 1 TPS and 8640 TPD, then maximum of 1 request can be sent per second and 8640 per day. Even if 1 TPS is there, once TPD is exhausted requests will be throttled.
Primary Account – This refers to the Amazon username (email address) and password that you used to create your Associates account and used to generate Product Advertising API 5.0 credentials.
Shipped revenue – This refers to the total sales volume of all items Amazon has shipped from orders resulting from clicks through links you created using Product Advertising API 5.0.
Also:
As soon as you create your Product Advertising API 5.0 credentials, you are allowed an initial usage limit up to a maximum of one request per second (one TPS) and a cumulative daily maximum of 8640 requests per day (8640 TPD) for the first 30-day period. This will help you begin your integration with the API, test it out, and start building links and referring products to your readers.
Your PA API usage limit will be adjusted based on your shipped item revenue. Your account will earn a usage limit of one TPD for every five cents or one TPS (up to a maximum of ten TPS) for every $4320 of shipped item revenue generated via the use of Product Advertising API 5.0 for shipments in the previous 30-day period. For correct attribution of shipped item revenue please ensure that you always call Product Advertising API 5.0 with the primary account credentials and retain all the URL parameters that the API returns in its response.
...
If you are trying to submit requests that exceed your account’s usage limit, or if your access has been revoked you will receive a 429 TooManyRequests error message from Product Advertising API 5.0. Please refer our API integration best practices to learn more on how to avoid these situations and optimally access the API.