| * Over how much time are the load metrics computed? For how long do they have to go above 85% to trigger a scale? => all metrics are computed in the more appropriate interval for each, and we improve this continuously. Main metrics are computed each 15 seconds today. We take the up scaling decision quickly, and we downscale less quickly, but this is very reactive. * Do you compute the average load across all scalers? Or some percentile? => Across scaler and only one, we try to avoid false positive by an infinite loop ;-) (and it works) I never remind a customer unhappy of this feature. * Can these parameters be tuned ? Can the load and the scaling decisions be seen (a part from the bill?) => you can manage how many you want to spent, it's important. But you can discuss with support to tune all of this. * Assuming other bottlenecks (like IO), you won't notice high CPU or RAM load, but you would notice a spike in response time. Do you allow, or have any plans, to include other metrics in the scaler or to allow customers to export custom metrics? => Many metrics are watch, I/O included. And we will add an API to get metrics in the future * Do you allow to spawn long running background processes. If yes, how does it interact with the CPU load based scaling? => Yes you can do it * Can the user add placement constraints when deploying an app in multiple DCs ? Can the scalers themselves span multiple DCs in the same region. If not do you plan offering access to configuring loadbalancers to serve traffic to multiple app instances serving as a single logical app? => Yep, all of this is in the task list for future region. |