I’ve tried optimizing database queries, but it seems to have no effect (also, I’ve heard that things like n+1 issues don’t matter on SQLite). I’ve even tried destroying and recreating the app, but it still feels the same. Sometimes as much as 8 seconds for a page to load.
I have another, far more complex app with the same setup that is a lot faster which is also on Fly.io.
Any ideas on where I could look for the cause of this slowness?
Since 8 seconds is incredibly slow, the first thing I’d do (at least for debugging) is make sure Fly isn’t turning all your machine(s) off and so starting a new one for a request. That will add X ms overhead. No idea how much but starting a new machine could add seconds of delay. That’s an option in the fly.toml. Check out this part:
Then make some requests and see if the issue persists. If not, solved
If it does, clearly that was not the issue and it’s somewhere else …
I don’t know much about Django but generally I’d recommend doing some kind of profiling. Normally it’s the database. SQLite should be fast but you never know. There are commercial tools with free trials, else this one (randomly found) looks free. That should show some info about the number of queries, whether any are particularly slow etc:
It’s definitely not the automatic stopping and starting, but that has bitten me before!
I can’t really make sense of what’s happening. It’s one Django view, and I’ve tried gutting it to remove more and more queries, but it doesn’t seem to matter.
If it’s just one view that’s slow, that would suggest it’s the app . Else if it was e.g the region, the network etc, that would affect all requests. Like I’m sometimes served from iad despite having lhr next door.
Loading a slow asset (image, js …)? Calling a slow external API? Total guesses I’m afraid! It would be a case of looking at what differs about that particular one I guess.
. Else if it was e.g the region, the network etc, that would affect all requests. Like I’m sometimes served from 