Heterogeneous v2 apps / machines

I’ve been trying to setup some more edge regions. I’m not sure if autostart/autostop will actually work as there are a lot of open/idle websockets per region, but I figure I can reduce the memory at least.

Barring better ideas, what I’d like to do is:

  • main regions - always on
  • edge regions - autostart=true, autostop=true, less memory

I’ve manually set the autostart/autostop on two machines, but it appears to get overwritten in a deploy? The soft/hard limits also need to be adjusted on the edge locations, but I’m assuming the soft/hard limits also get set on fly deploy.

Is it possible to have this type of setup or is there some alternative?

You can do this with process groups:

[processes]
phat = "<cmd>"
edge = "<cmd>"

[[http_services]]
processes = ["phat"]
internal_port = 8080
force_https = true
auto_stop_machines = false
auto_start_machines = true

[[http_services]]
processes = ["edge"]
internal_port = 8080
force_https = true
auto_stop_machines = true
auto_start_machines = true

This is a bit of a hack, but it’s worth testing.

If that doesn’t work, your best bet is to disable auto_stop_machines and then make your app process exit when you want to.

2 Likes

I’ll give this a shot.

Any thoughts on scheduled autoscale/downscale?

For instance, from midnight to 8 am, no need for 3 instances in the US, can probably scale down in both size and count. Same in Europe/Asia.

That may be a better fit for many applications.

1 Like

I don’t think that’ll work, unless you also manage starts yourself. Our autostart behavior is per region. If you get a request in, say, Singapore, we will start a machine in Singapore if we need to.

We’ve thought about follow the sun workloads. We just don’t know quite how to expose it, and surprisingly few people seem to want it.

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.