Performance issues after upgrading from Prisma 2.14.0 to 2.15.0 (or 2.16.0)

Bug description

Overall performance has been dramatically reduced since upgrading to Prisma 2.15.0 (or 2.16.0) from 2.14.0. More details and specific examples in the sections to follow.

How to reproduce

This is unfortunately something I can’t share for you to reproduce yourself.

Steps (that I took) to reproduce the behaviour:

1. Test a query 3 times against the API on 2.14.0, calculate average response time.
2. Update to 2.15.0 or 2.16.0.
3. Test the same query 3 times against the API, calculate average response time.
4. Note, for a specific query, an average response time of 1.76s vs. 28.59s.

Note that I’m testing with a free Heroku hobby dev database so a certain level of performance/latency is to be expected but I’ve had this setup for a few months now and it’s been fine the the whole time until upgrading from 2.14.0. Nothing on the server has changed.

Expected behavior

Average performance should remain the same or improve between Prisma versions.

Prisma information

I’d rather not share my schema and queries/mutations publicly but I’m happy to share this directly to somebody at Prisma (as I have done already).

Environment & setup

• OS: Ubuntu 20.04 (LTS) x64 ($5 Digital Ocean Droplet)
• Database: PostgreSQL (Heroku free hobby dev)
• Node.js version: v14.15.4
• Prisma version: 2.16.0
• Other: I’m using nexus-plugin-prisma

Dependencies:

"dependencies": {
  "@prisma/client": "^2.16.0",
  "@sentry/node": "^6.1.0",
  "@sentry/tracing": "^6.1.0",
  "apollo-errors": "^1.9.0",
  "apollo-server": "^2.19.2",
  "bcryptjs": "^2.4.3",
  "dotenv": "^8.2.0",
  "fs-extra": "^9.1.0",
  "google-auth-library": "^6.1.6",
  "graphql": "^15.5.0",
  "graphql-middleware": "^6.0.3",
  "graphql-shield": "^7.5.0",
  "jsonwebtoken": "^8.5.1",
  "mailgun-js": "^0.22.0",
  "nexus": "^1.0.0",
  "nexus-plugin-prisma": "^0.30.0",
  "node-fetch": "^2.6.1"
},
"devDependencies": {
  "@types/bcryptjs": "^2.4.2",
  "@types/fs-extra": "^9.0.6",
  "@types/jsonwebtoken": "^8.5.0",
  "@types/mailgun-js": "^0.22.11",
  "@types/node": "^14.14.25",
  "@types/node-fetch": "^2.5.8",
  "prisma": "^2.16.0",
  "ts-node": "^9.1.1",
  "ts-node-dev": "^1.1.1",
  "typescript": "^4.1.3"
}

Misc

I isolated all changes to my codebase for the time between being on 2.14.0 and now, on 2.16.0, and you can see that I’ve not really done that much. I can give more details on the diffs in these few commits if you want but the messages should be clear enough, I imagine.

• I added &pool_timeout=0 as suggested on Slack when on 2.15.0 and it made no difference. I’m still using it on 2.16.0.
• I’ve been back and forth between my latest state (on 2.16.0) and the last commit on 2.14.0 a few times today and I can reproduce the issue every time, i.e. it feels much slower/worse on 2.16.0.

Finally, I sent the same 3 requests 3 times each on both 2.14.0 and 2.16.0 and here are the average response times:

2.14.0 vs. 2.16.0
Get X (query): 1.76s vs. 28.59s
Get Y (query): 365.66ms vs. 422ms
Sign in (mutation): 438.66ms vs. 625.33ms

[janpio]

Thanks @darrylyoung for providing an excellent reproduction via another channel! ❤️

I could pinpoint this problem to another existing issue: https://github.com/prisma/prisma/issues/5274 Your app is experiencing a problem where queries unfortunately are not optimized, that should be optimized. As this query already creates quite a few Prisma Client queries in Nexus under the hood, this sums up to quite a lot of queries to be sent to the database server.

I suggest you follow #5274 and stay on 2.14 until this problem is fixed. Sorry.

@GCastilho I would assume you are experiencing the same problem. You can check by logging the database queries with https://www.prisma.io/docs/concepts/components/prisma-client/logging#log-to-stdout and comparing the output of 2.14 with a more recent version - expect the log file to be much longer.

[janpio]

Hey @darrylyoung, very eager to look into that. Can you tell me who you shared the code, schema or query with before?

I am especially interested in “Get X” of course as it seems the best candidate for an isolated reproduction. An app that just runs that query, deployed twice against the same database - once with 2.14 and 2.16 would be the dream reproduction I am hoping to get to.