Dynamic Scaling in DXP - improve performance and reduce costs
The default hardware SKU for Optimizely is P1V3. P1V3 only has 2 cores and P2V3 has 4 cores. Because the number of cores available to the system dictates the number of default threads the system attempt to regulate, it would be best to deviate away from our current default hardware SKU, P1V3 to P2V3, instead. However, doing so would increase costs which we do not want to do necessarily. This is a proposal to decrease costs while simultaneously increasing hardware resources during peak hours.
The idea is to increase a customer's lower environment hardware to P2V3 during "working hours" (to be defined by the area the company hosts their hardware in by default), then decrease it after hours.
The result would be to decrease hardware down to a minimum between approximately 5pm and bump it up again at approximately 9am. But, bump it up to a higher SKU that enables them to operate faster and better
Based on my calculations, it appears that we could save approximately $700k/yr in doing so (calculation based on retail prices, not contracted prices).
See the attached spreadsheet for projected reduction in costs.
A self-service ability would be necessary to be able to temporarily scale up hardware resources. For example:
The user would have the ability to push a button to scale up to P2V3 if between an extended hour (between 7am and 7pm).
The user would have the ability to scale up additional instances for a short window of time and to keep hardware scaled to P2V3 for, say 4 days per month (4 days of load testing for example).
This would enable the partner/customer development team to have better control over their resources while simultaneously dropping our costs another $500k-700k approximately.
-
Here's an animated gif of navigating within Chik-Fil-a.
-
Here's what the CMS admin experience looks like when loading something fresh. It's very slow. It takes about 13 seconds to load the page in the admin.