Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend Benchmarking Suite #548

Closed
mavilein opened this issue Mar 3, 2020 · 3 comments
Closed

Extend Benchmarking Suite #548

mavilein opened this issue Mar 3, 2020 · 3 comments
Assignees
Milestone

Comments

@mavilein
Copy link
Member

mavilein commented Mar 3, 2020

Recently @pimeys did some initial benchmarking of the major the code changes related to the AUMFIDARR project. This yielded some first very good insights into the impact of those changes. I think we should invest more into this testing setup to also understand the following aspects:

  • We should benchmark how the resolving of many to many relations changed. (the initial testing did not have a test for this imo)
  • We should benchmark how the resolving of one to many relations behaves depending on which side of the relation is traversed. We have different slightly code paths for each side. E.g. we should benchmark retrieving all posts for a given blog but we should also measure retrieving the related blog for a given post. (the original testing only executed one side imo)
  • For all queries we should generally measure the impact on the CPU load of database and query engine. My expectation is that the database shows less CPU load with the new appraoch since we moved joining logic from the db to the query engine.
  • We should benchmark the performance impact of pagination. Specifically we should not only measure top level pagination but also nested pagination as those have very different work profiles.
@mavilein mavilein added this to the Preview 24 milestone Mar 3, 2020
@divyenduz divyenduz modified the milestones: Preview 24, Preview 24 New Mar 3, 2020
@pimeys
Copy link
Contributor

pimeys commented Mar 4, 2020

  • Do self-relations count? Such as:
model User {
  id Int @id
  friendWith User[] @relation("FriendShip")
  friendOf User[] @relation("FriendShip")}
  • This should be easy.
  • I don't really trust these measurements and I don't see a point of really measuring this. Yes, we do less cpu in the db, but what matters to our users is how fast we can query.
  • This was removed due to us comparing ourselves to Hasura, which doesn't have nested pagination. We can add it back.

@pimeys
Copy link
Contributor

pimeys commented Mar 4, 2020

New queries:

query ComplexRelationsFromOppositeSide {
  findManyComment(where: { id_lt: 100 }) {
    id
    content
    post {
      id
      content
      author {
        id
        firstName
        lastName
      }
    }
  }
}

query ManyToManyFromSideA {
  findManyUser(where: { id_lt: 100 }) {
    id
    firstName
    lastName
    friendWith { id firstName lastName }
  }
}

query ManyToManyFromSideB {
  findManyUser(where: { id_lt: 100 }) {
    id
    firstName
    lastName
    friendOf { id firstName lastName }
  }
}

query NestedPagination {
  findManyUser(first: 100) {
    id
    firstName
    lastName
    posts(skip: 5, orderBy: id_DESC) {
      id
      content
      comments(first: 3, orderBy: id_DESC) {
        id
        content
      }
    }
  }
}

@pimeys
Copy link
Contributor

pimeys commented Mar 19, 2020

this is done.

@pimeys pimeys closed this as completed Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants