Anyone else facing problems due to too many tasks ...
# orm-help
k
Anyone else facing problems due to too many tasks produced by Prisma Client? It seems that our task queue is flooded on some requests, leading to a
RejectedExecutionException
as well as memory spike that temporarily takes down our server (probably due to moving pages from memory to swap). Rough datamodel:
Copy code
type User {
  decks: [Deck]
}
type Deck {
  creator: User!
  cards: [Card]
  learningState: [LearningState]
}
type Card {
  repetitions: [Repetition]
}
type Repetition {
  ...
}
type LearningState {
  ...
}
Now we are using Prisma Client and our resolvers are basically set up according to the [guide](https://www.prisma.io/tutorials/a-guide-to-common-resolver-patterns-ct08#scenario-implementing-relations-with-prisma-client):
Copy code
export default {
  Query: {
    decks: async (_, __, ctx: IContext) => {
      const userId = …;
      return prisma.decks({ where: { creator: { userId } } });
    },
  },
  Deck: {
    cards(parent) {
      return prisma.deck({ id: parent.id }).cards();
    },
    // Same for creator and some other fields
  },
}
Let’s assume we have a user with a single deck containing just two cards. This is our query:
Copy code
decks {
  ...
  learningState { … }
  cards {
    ...
    repetitions { … }
  }
}
This produces the following queries (some batched together, shown by enabling tracking of slow queries and setting threshold to
0
):
Copy code
1. decks (scalars)
2. batch: [deck#1 cards, deck#1 learningState]
3. batch: [deck#1 cards, deck#1 learningState] (exact duplicate of 2.)
4. batch: [card#1 repetitions, card#2 repetitions]
5. batch: [card#1 repetitions, card#2 repetitions] (exact duplicate of 4.)
As can be seen, there are a couple of duplicates. We would like to keep using Prisma Client while reducing the number of queries so that the task queue is not flooded and our server stays alive 🙂 I’ve tried to make use of fragments but the cards are still queried individually. Is it possible to eliminate the queries for each individual card? Are we correct in the assumption that queries of this form (e.g. with 1000+ cards) could cause memory spikes and thus downtime? Anyone else facing these problems? Thanks! (Happy to post this somewhere else if helpful) prisma-client-lib, docker image, CLI all at 1.34.3. Update: Changed post to reflect current situation.
h
If queue is getting full, you can increase the queueSize. First of all please ensure that your Prisma server is on 1.34.3 as it has some fixes related to this. Then you can increase the queueSize parameter which was introduced in the following release:https://github.com/prisma/prisma/releases/tag/1.32.1
Copy code
version: '3'
services:
  prisma:
    image: prismagraphql/prisma:1.34
    restart: always
    ports:
      - '4466:4466'
    environment:
      PRISMA_CONFIG: |
        port: 4466
        databases:
          default:
            connector: postgres
            host: postgres
            port: 5432
            user: prisma
            password: prisma
            queueSize: 10000
  postgres:
    image: postgres:10.3
    restart: always
    environment:
      POSTGRES_USER: prisma
      POSTGRES_PASSWORD: prisma
    volumes:
      - postgres:/var/lib/postgresql/data
volumes:
  postgres: ~
The default queueSize is of 1000 ops
k
Thanks for the reply! We are already on 1.34.3. Will try to increase the
queueSize
. Any idea regarding the duplicates or getting rid of the individual card queries? Thanks in advance!