Overview
Having a flash sale or a product launch? Especially if you are launching limited-time pricing or inventory, Aspenware very highly recommends, almost mandates, scaling for these scenarios. We define a flash sale as a short period of time where your resort will be driving 300% more traffic to your e-commerce site than is typical (i.e. a product launch, a pass sales price deadline, a high volume special event that sells out quickly, etc.) Please take the following steps at least 7 business days prior to the flash sale to notify and work with your Aspenware representative to ensure your site has the proper Azure tier for the sale and product configuration questions answered ahead of the sale.
IMPORTANT: If you aren’t already set up for auto-scaling in Azure, you should be. Talk to your Aspenware Representative about configuring this in Azure along with alerting today. However, there are some situations where even auto-scaling doesn’t cover you. This article highlights scenarios where you should be considering Azure intervention beyond auto-scaling for specific very high traffic events.
Prerequisite Checklist
Determine if you need to scale your site by looking at data and answering key questions.
Determine the specifics of your flash sale and email Aspenware at ski-support@aspenware.com at least 7 business days in advance of any flash sale.
If Queue-it is used, update safety net max user redirects following Aspenware’s confirmation of scaling.
1. Determine if you need to scale your site
If you are unsure whether your upcoming sale will cause performance issues in the shop, check Google Analytics traffic overview filtered by the hour for data from last year's sale. Better yet, if you have Azure Application Insights data for last year, check Metrics in Application Insights filtered by the minute for data from last year's sale.
If working with Google Analytics Data
If you see that the number of sessions for an hour at any hour during the day of last year's sale met or exceeded the following user counts according to Google Analytics in a single hour, the site should be scaled.
If your site is NOT set up for autoscaling: ~300 users within a single hour
If your site IS set up for autoscaling: Over 500 users within a single hour (especially if these users will “surge” - meaning the majority will hit the site within a 5-20 minute period)
For example, this spike in users would require a scale:
This traffic trend for users, however, would not require a scale (assuming this resort had autoscaling configured):
If working with Azure log-based metrics data
If you see that the number of sessions for any 3 min increments during the day of last year's sale met or exceeded the following user counts according to Azure data in a single hour, the site should be scaled.
If your site is NOT set up for autoscaling: ~30 users within a single 3 min period
If your site IS set up for autoscaling: Over 200 users within a 3 min period
For example, this spike in users would require a scale:
This traffic trend for users, however, would not require a scale (assuming this resort had autoscaling configured):
If you don’t have prior data
If you don’t have prior data that is relevant to your scenario this year, answer the following questions.
Am I putting a highly sought-after product on sale and announcing a specific start time to a large group of customers? - If yes, there is a strong case for scaling. If no, proceed to the next question.
Are there hard inventory caps or limited-time pricing offerings that are expected to sell quickly or drive high demand? - If yes, there is a strong case for scaling. If no, proceed to the next question.
What do I scale? My DB, my App Service, both?
Each site is set up with a database and app service in Azure to power your site that is cost-effective for your resort to maintain over time. We also recommend implementing autoscaling so that your store can flex with normal increases to traffic. Talk to your Aspenware Service Representative to set this up.
The normal settings can handle a typical load to the site; however, when traffic exceeds a normal load by 3x within a very short period of time, which is usually driven by flash sales, then a higher tier database and/or app service is required to handle the load for the period of the flash sale.
What will this cost me?
Azure charges by the time increment, rather than by the month, so if your site is scaled out for a minute, an hour, a day, or even a week, you will only pay the difference of cost for the minutes used, rather than for the full month. For example, a p2v2 database is $.40 per hour. If a flash sale runs 24 hours, the cost of having a performant database (scaling to 2 instances of a p2v2 database for 24 hours) is less than $10. The cost is negligible scaling up during a flash sale, but the impact of having a database that can handle your load during the period of a flash sale can make or break the success of your sale. In the event you are on the wrong tier during a flash sale, the worst-case scenario is that the traffic will bring your site down, and the best-case scenario is that the site will have poor performance.
IMPORTANT: While scaled out, Aspenware Commerce Admin changes will not take immediate effect on the store and can take between 1 hr and 24 hrs to propagate. This increases the importance of testing products end to end prior to any launch events. If in an emergency, a change with admin needs to be made and immediately take effect while your site is experiencing high traffic, you have the following options:
If using Queue-It - Make the change in admin, then pause the queue, which stops letting additional users in the site - wait until CPU % drops below 40% for 2-3 minutes in Azure Application Insights, then scale down to 1 instance. Once scaled-down, the change will propagate and you can scale out and restart the queue.
If NOT using Queue-It - Make the change in admin, close the store, wait until CPU % drops below 40% for 2-3 minutes in Azure Application insights, then scale down to 1 instance. Once scaled-down, the change will propagate and you can scale out and re-open the store.
For more details on various admin changes and how long different change types take to propagate in a scaled environment, check out this Release Guide.
2. Determine the specifics of your flash sale and email Aspenware Commerce
Answer the following questions about your upcoming flash sale:
When is the flash sale? (Date and time)
What is going on sale? (The more detail the more we can help brainstorm with you)
What load are you expecting? (Send data from section 1 above)
How long do you want to scale up your database/ how long do you expect the sale to last?
Identify any questions on product setup, requests for support, training, testing, etc.
Please indicate whether you use a Queue-it safety net.
With this information, we can recommend the right database, expected costs, set up product training calls, block out time for support and testing, adjust queue-it, and more.
We recognize that flash sales are important for your business and having proper product setup and testing support for the products going on sale is important. We are happy to answer any product setup questions, help with configuration, testing, or just be available as you are working to answer questions. If you need any assistance with product setup to prepare for the flash sale, please email Aspenware at ski-support@aspenware.com 7 business days in advance of any flash sale so that we have adequate time to address your product setup questions and needs.
With this information, we can recommend the right database, expected costs, set up product training calls, block out time for support and testing, adjust queue-it, and more.
Aspenware will send a calendar invite to note when we are scaling your site up with the new Azure levels indicated as well as a calendar invite to note when we are scaling your site down with the baseline Azure levels.
3. If Queue-It is used, update safety net max user redirects
If you use Queue-It, please update your safety net max user redirects (throughput) to match with the level your site is set to using the table below BOTH when scaled up AND when scaled back down.
If using standard Aspenware Commerce Login
Application Service Level | Number of (scaled) instances | DB Level | Queue it Max User Redirect (users per min) |
|---|---|---|---|
p2v2 | 1 | s3 | 10-50 |
p2v2 | 2 | s3 | 20 |
p2v2 (level Queue-it should be set if autoscaling configured)* | 3 | s4 | 40 |
p2v2 | 4 | s4 | 80 |
p2v2 | 6 | s4 | 100 |
p2v2 or p3v2** | 6+ | s4+ | >100 |
* If a store is a multi-store divide this level between the multiple stores. (i.e 30 to store A and 10 to store B)
**If you’d like to scale beyond 100 users per minute, please contact Aspenware.
If using Aspenware Identity Authentication for Commerce
Application Service Level | Number of (scaled) instances | DB Level | Queue it Max User Redirect (users per min) |
|---|---|---|---|
p2v2 | 1 | s3 | 15 |
p2v2 | 2 | s3 | 40 |
p2v2 (level Queue-it should be set if autoscaling configured)* | 3 | s4 | 60 |
p2v2 | 6 | s4 | 100 |
p2v2 or p3v2** | 6+ | s4+ | >120 |
* If a store is a multi-store divide this level between the multiple stores. (i.e 30 to store A and 10 to store B)
**If you’d like to scale beyond 100 users per minute, please contact Aspenware.
HINT:
For more details on scaling considerations, check out this Release Guide.
For more details on Queue-It, check out this Release Guide.