`findOne` optimization

To quote from an earlier specs issue:

One of the main usecases of Photon Prisma Client is to use it inside a GraphQL server. The resolver system of a GraphQL server is prone to suffer from the N+1 problem. To mitigate this problem users can choose to implement the DataLoader pattern within the application server. This burdens our users with unnecessary work that is not related to their core domain. This issue explores how we could include a DataLoader implementation within Photon Prisma Client.

As a first step we want to look specifically into optimizing findOne queries by batching them.

[pimeys]

Memo: unsurprisingly faster with optimization. Green: batching without optimization Purple: with optimization Y: response time in nanoseconds X: requests per second

Tested three queries in batches of 100, $user_id randomized from 1 to 3000. 3000 users, 30000 posts and 30000 comments.

query NoJoin {
  findOneUser(where: { id: $user_id }) {
    firstName
    lastName
  }
}

query OneJoin {
  findOneUser(where: { id: $user_id }) {
    firstName
    lastName
    posts {
      content
    }
  }
}

query TwoJoins {
  findOneUser(where: { id: $user_id }) {
    firstName
    lastName
    posts {
      content
      comments {
        content
      }
    }
  }
}

[maartenraes]

@mavilein We didn’t really solve it, we just added timings just before and just after resolvers to see how fast queries were resolved.

1. Doing all saved up queries in one go (what batching would look like) manually in Postgres takes about 12ms, with the exact where on the top level. So I don’t think that’s the issue.
2. Activities doesn’t have that many entries, during our tests about 40. So even if Postgres would be scanning it shouldn’t take that long.
3. We have put indexes on all foreign keys related to activities, also on all fields that are used in the where (deletedAt, departmentId, etch) both singular and combined indexes.

I do agree that it’s a hefty query. But production workloads are gonna go way beyond this I think 😄 The N+1 is definitely the big slowdown in this case, the worst thing about the N+1 is probably the overhead it takes for every query to resolve and go back and forth between Prisma-client and the database. (Which both run on localhost, so also shouldn’t be an issue, deployed on GCP both running in Cloud Run we have similar timings)

My example is also a findMany on activities, I don’t think a findOne would be as bad as a findMany. Think batching would be much more usefull in findMany than a findOne. But then again, the logic from findOne would probably be reuseable in de findMany

I don’t mind open ended comments, performance surely isn’t as straightforward as it seems!