Deployment

[yashh]

Wondering how does deploying work with prisma?
Right now I am running prisma py fetch and prisma migrate as part of deployment which is fetching the binaries and migrating the DB.

However why I spawn the gunicorn server, each server process is spawning one instance of prisma-query-engine-debian-openssl-1.1.x on a new port. Since prisma is querying DB and returning data I think one process should sufficient handler many server process. Anyway I can control the query engine to spawn on a specific port and control it?

[RobertCraigie]

Hey @yashh! You currently cannot control the query engine server as this is intended to just be an implementation detail and isn't designed to be exposed to users. You would be able to achieve what you want but it would not be nice and would require monkey patching.

What does the entry point file look like for your server? And how are you starting it? I'm not aware of the details of how gunicorn works but it may be possible to share the Prisma query engine server depending on how gunicorn spawn the multiple server processes.

[yashh]

@RobertCraigie On app startup I am calling await prisma.connect() and this triggers the connection. I sense about 3-4 second pause on production server so it must be those subprocess opens thats causing the delay.

async def startup():
    logger.debug("Running app startup")
    from core.db.connection import prisma

    if not prisma.is_connected():
        await prisma.connect()
    cache.setup(config.REDIS_DSN)```

[RobertCraigie]

Ah yeah that will most likely be the connecting to the database that takes that time.

I've looked into how gunicorn works and it spawns the worker processes in a way that makes it incompatible with just naively sharing the Prisma connection.

What database are you using? I'd recommend either limiting the number of connections that Prisma opens for each worker (using connection string arguments) or using some form of connection pooling directly on the database server.

The fact that multiple query engine servers are spawned for multiple worker processes isn't something you should really worry about as it is standard with other database drivers / ORMs. The difference with them is that they will typically open up the connections within the same process so it is just not transparent that the same behaviour is occurring.

[yashh]

Postgres 14
Did you mean like this?

"postgresql://root:@127.0.0.1:5432/databasename?connection_limit=1"

[RobertCraigie]

@yashh yes exactly right, see https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/connection-pool#setting-the-connection-pool-size

Also you would probably be better off with at least 3 connections per pool but that depends on the computing power your database server has and how many workers you're running.