139
Autoscaling
in progress
w
webservices
Scale out and scale in automatically based on a metric such as CPU utilization rate. Scale out should add a specified number of instances, run build and deploy, and then automatically add it to the cluster. Scale in should remove the instance from the cluster and destroy it.
Log In
Anurag Goel
Autoscaling is now available in early access! Please see https://community.render.com/t/autoscaling-available-in-early-access/611 for details.
Activity
Newest
Oldest
A
Andy Chong
Adding Memory utilization will be great!
Anurag Goel
@Andy Chong: how does your app's memory increase with load? A lot of memory-bound apps require
vertical
autoscaling, which is on our roadmap. We'd love to know more about workloads that can benefit from memory-based horizontal autoscaling.Anurag Goel
Autoscaling is now available in early access! Please see https://community.render.com/t/autoscaling-available-in-early-access/611 for details.
P
Peter Schröder
👍 nice! currently evaluating getrender and it looks great. not having an autoscaling is a major blocker though. if you have a beta-channel or something like this, i'd love to participate in a preview.
Anurag Goel
in progress
We're going to start out with horizontal autoscaling based on memory and CPU utilization targets. Stay tuned!
E
Emmanuel Amodu
@Anurag Goel: For vertical scaling, taking a snapshot of the current service would make more sense for me, as sometimes we have temporary data (on sqlite) we would like to persist as the system scales up.
P
Peter Schröder
@Anurag Goel: any ETA on the memory based targets? our web and worker instances are both memory bound and the current CPU utilization is not a good autoscaling metric. it would also be great to allow configuration of the number of upscale and downscale instances and the delay between scaling events. this will help us with bursts of usage that we regularly see in our app.
Anurag Goel
@Peter Schröder: how does your app's memory increase with load? A lot of memory-bound apps require vertical autoscaling, which is on our roadmap. We'd love to know more about workloads that can benefit from memory-based horizontal autoscaling.
P
Peter Schröder
@Anurag Goel: our workload mangles a lot of photos and is more io and memory bound when parts of the photos are loaded into memory. There is a low correlation to CPU. Horizontal autoscaling sounds promising as we see a lot workers dying when we reach a memory threshold in spikes.
Anurag Goel
@Peter Schröder: memory based autoscaling will be available when we launch autoscaling publicly.
D
Daniel Meechan
Our team's considering switching to Render but not having autoscaling (either vertical or horizontal) is a blocker for us. Is this planned for 2020 or can we expect it to arrive later?
Anurag Goel
@Daniel Meechan: horizontal autoscaling is definitely planned for this year; most likely this fall or sooner.
Anurag Goel
planned
y
yoran
For the metric, we've had good results with autoscaling based on queue time in the load balancer that is in front of the application servers. This is the approach taken by the Rails Autoscale addon on Heroku (https://elements.heroku.com/addons/rails-autoscale). We found queue time to be a much better metric for autoscaling than response time, which is used by the default Heroku autoscaler.
A
Andy Chong
@yoran: +1
Anurag Goel
under review
O
Omri Cohen
This is the number one feature preventing me from migrating my production servers to Render. Without this ability, I will either have to overpay excessively for servers, or expect downtime during spikes in traffic.
Anurag Goel
@Omri Cohen: which metrics would you like to scale on?
K
Kory Nunn
@Anurag Goel: average CPU %, number of concurrent connections, memory. With sane defaults but customizable.
EG: ~10s moving average CPU, memory, or max connections above 85% -> spin up another instance.
Anurag Goel
@Kory Nunn: sounds good.
A
Artur Trzop
@Anurag Goel: Also something like requests per minute threshold would be cool. Let's say if server gets 300 RPM then scale up. If it goes down 150 RPM you scale down. Would be also cool to connect this with time. For instance if for 10 minutes requests are lower than 150 RPM then scale down.
I tested RailsAutoscale on Heroku with queue time which sounds cool but my app has spikes of traffic in short period of time (in a few seconds there are big hits to API 80-150 RPS). And queue time wasn't working good enough (most of the time servers ended up over provisioned) despite testing various queue time thresholds.
I guess autoscaling is just complex problem and a lot of depends on how app is working, what endpoints are slow or what's the traffic during the day. I can think about idea to solve it like the one mentioned above but I have no clue if this would be good solution until tested on real production app.
m
max
A range that you can scale to would also be great! E.g. never drop below 2 instances and never go above 10.
Load More
→