When I looked at Fly last year I didn’t see a compelling story for Laravel on Fly. It seems that has changed now that Fly has a Laravel specialist. While relooking at it I saw machines. After reading the blog post I am actually really excited about the scaling down to 0 and only paying for image storage.
It makes me want to deploy a machine or two to each Fly region because its costing me pennies unless its actually used. And since Fly uses Anycast IPs that should make the app very snappy for all users regardless of where they are.
My big question about this is where it says (emphasis added):
I should clarify: our infrastructure is fast to run start operations. Your application boot time is something you should optimize.
So this is the question: does anyone have an idea on what’s faster, a local machine without octane or a central machine always running with octane? Because obviously you can’t keep your Laravel app in memory on a machine that’s spun down to 0. I tend to think the network latency of a single server would be greater (for most users) than an full bootup of Laravel, but I am honestly just guessing
Don’t think anyone’s profiled it specifically with Octane. Usually (and like you identified), if your users are spread across the world, spinning up a Machine closer to them might be more performant (syncs nicely with night/day; work/leisure cycles, too). Recall that it is upto the app to decide just how long it should idle around before it quits.
flyctl logs do contain information on how long it takes to boot-up a machine and get the main process going.
Try it out and let us know how Octane performs! (:
The part about startup cost… At some level, it is on the docker image that is being deployed. I’d imagine a large docker image is likely slower to setup than a smaller one (like distroless images or alpine images). Related: Difference between AWS Lambda and Fly Machines? - #2 by ignoramous
Another area is to ensure the main (entrypoint) process itself starts up in a jiffy.
VM snapshots for Machines may happen in the near-term, which should then improve startup times considerably and relegate Your application boot time is something you should optimize to merely an academic exercise.
Here’s a surprise you may hit: Fly doesn’t currently have a way to turn off an idle machine itself. A machine will stop when the program set to run exits with a zero (success) status code.
This might change in the future, but currently, the Fly is not tracking if web requests have stopped coming into an app.
That means you’ll need to devise a way to have Octane exit (if it’s idle) yourself.
I’m not familiar enough with Octane to know how possible that is, but it seems feasible and like something that’s be fun to investigate. Perhaps Octane emits events when a new request comes in?