Hello, I just deployed an app to test Fly, and the response times are rather slow.
I’m waiting for support to be able to upgrade my VM to a dedicated one.
Is using ga Shared CPU the reason for slowness?
Hi,
It’s possibly the CPU, however that would depend on exactly what your app does. If it does something that involves a lot of CPU effort, that would explain it. But it’s more likely to be an issue elsewhere. For example if your app connects to a database, and that is slow to return the results, it would result in turn in a delayed response to the initial request. Generally most time is spent doing I/O. To debug the bottleneck it would be a case of putting some logging in your app to see the request flow and seeing the timings.
Thanks for your input.
The database used is also hosted on Fly.io, and it is attached to my Fly.io app. So the issue shouldn’t be there really I think.
I’m not sure where to start logging in exactly, I’m using a standard Remix app with a deployment stack that is specifically designed for Fly.io.
The initial response is always slow as shown in the picture above.
Any ideas on what to log?
No problem.
I mean the database connection is probably fast (though there will always be more overhead on the first request, establishing the connection, than on the second request) however it would depend on the query being run. For example a simple SELECT should return in milliseconds, but if you are doing something involving JOINs, that kind of query will take longer. I forget what logging is provided but I’d just start sticking some log lines throughout the server-side actions with a timestamp/string so you can know exactly what time each point is hit (and then look in fly logs which shows the most recent X lines). So e.g if you saw the time before the query runs is e.g 14:10:00.000 and after it is 14:10:00.001, well clearly that’s not the issue. But e.g if you saw the time before the query runs is e.g 14:10:00.000 and after it is 14:10:02.000, well then you know that took two seconds to return and so that’s where the bottleneck is.
Also, cache as much as possible. See: Remix | Performance.
God, I just discovered the issue completely by accident.
My database is in California, while my app is in Frankfurt. Not sure why Fly assigned two different regions.
But I’m 99% confident this will solve the problem…
