How should I avoid a long load time for my rails app after all machines have stopped?

[Ollieh-m]

I have a small rails app running which gets very minimal traffic - it’s only used by a few people. When no-one has used it for a bit of time, I’d still like it to be available (without a long delay) the next time someone visits, but currently, if the machines have stopped, it takes ~8 seconds for the site to load.

When I visit the site after the machines have stopped, I see (in the logs) the machines start quickly:

2023-05-05T09:57:55Z proxy[3d8d9349be9658] lhr [info]machine started in 544.039764ms
2023-05-05T09:57:55Z proxy[3d8d9349be9658] lhr [info]machine became reachable in 7.189982ms

Puma starts to boot 4 seconds later:

2023-05-05T09:57:59Z app[3d8d9349be9658] lhr [info]=> Booting Puma

It is booted two seconds after that:

2023-05-05T09:58:01Z app[3d8d9349be9658] lhr [info][524] - Worker 0 (pid: 538) booted, phase: 0

I’m wondering how I should reduce this load time…

• I think I could set auto_stop_machines to false - which would ensure the machines don’t ever stop. But if I have two machines, does that mean both would always be running? How could I allow scaling down to 1?

• I’ve noticed that when a machine starts, db:prepare is run as part of the docker-entrypoint script:

2023-05-05T09:57:55Z app[3d8d9349be9658] lhr [info]Preparing to run: `/rails/bin/docker-entrypoint ./bin/rails server` as rails
...
2023-05-05T09:57:58Z app[3d8d9349be9658] lhr [info]D, [2023-05-05T09:57:58.625791 #530] DEBUG -- :    (1.2ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC

Is that a problem? Should migrations be handled as part of the deploy process instead of the machine startup process?

• Is there some other way?

Appreciate any advice

[rubys]

@Ollieh-m

I think I could set auto_stop_machines to false - which would ensure the machines don’t ever stop. But if I have two machines, does that mean both would always be running? How could I allow scaling down to 1?

You were initially provided with two machines as that is a common configuration. Feel free to increase or decrease the number to meet your needs. You can use the fly machine command to first list the machines and then destroy one of them.

@Ollieh-m

I’ve noticed that when a machine starts, db:prepare is run as part of the docker-entrypoint script

You can move when this is run by editing your fly.toml: see scaling in the docs, while the description there is focused on scaling up, it also applies in your case. As described there, if you have not made other changes to your Dockerfile you can use the generator to make these changes – you can also ask it to show you the diffs before applying the changes. Of course, you can also make these changes directly.