LiteFS: Slow queries when deployed, quick locally

I’m noticing differences in read speeds on LiteFS queries between my local environment and the one deployed to Fly. The same query takes locally around 120 ms, whereas on Fly it takes roughly 350-400 ms. This is a huge difference and it makes my app sluggish. This is timed with console.time and console.timeEnd in JS.

LiteFS is referred to as “in core”, and that it should be “lightning fast”. I feel like something is off here. Is something off with the volume mount? Note: I’m using LiteFS Cloud on top of this. My machine config looks like:

[mounts]
  source = 'litefs'
  destination = '/var/lib/litefs'
  initial_size = "2GB"
  auto_extend_size_threshold = 80
  auto_extend_size_increment = "1GB"
  auto_extend_size_limit = "5GB"

[vm]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 512
  processes = ["app"]

The dataset is about 25 MB, containing (roughly) about 3k rows in one table, and 70k rows in another.

Maybe something memory/ram related could be at play as well?

Thanks in advance.

2 Likes

This part would be my own first guess, actually…

They mainly are for things that can afford to be sluggish, in a sense:

I stubbornly use one in ORD for latency-sensitive tasks, and the subjective variation really is big—ranging into borderline unusable on weekdays now, right before the end of Chicago business hours, :pizza: :dragon:.


Memory is ever another one of the plausible culprits, though, e.g., Node GC nuances.

1 Like

Added machines

Hi again!

I realised that my foreign keys (used in joins) were not indexed properly. I actually didn’t know they weren’t indexed by default.

Adding indexes to those FK:s took performance (on Fly) from the above mentioned numbers, to around 5 ms.

Good lesson learned!

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