I see that it takes about 3 seconds to instantiate...
# orm-help
l
I see that it takes about 3 seconds to instantiate the JS/TS prisma client (Prisma 1) on a GCP cloud function. Since these (and similarily cloud run instances) are recycled fairly often, is there any best practice advice on how to structure this to avoid such delays?
m
I guess you're talking about cold starts?
l
@manuel yes
m
It's a known problem with serverless. It's not prisma what takes that long, it's the spinning up of the worker in gcp.
You can do workarounds if it's important to keep the function warm.
make the function "ready to receive" time longer - meaning it should stay warm longer.
and ping the function with ah cron job like every 15 minutes or something like that.
I don't know much about your project but you could also look at cloudflares workers which have a cold start of basically 0ms.
if you're using next.js it would make sense to try them out as the changed to cloudflare in their latest version I think it's next.js 12.
but with gcp, aws, azure you'll always have the coldstart problem...
l
Oh, I didn't mean that the observed delay was in the cold start itself, but the actual instancing of Prisma. But I may have been too fast, it seems like the average instancing time is quite a bit better. Will have to observer for longer.
m
if the function is warm it should take too long to instantiate
shouldn't
l
Can an instance start running before it is warm so to speak? At lower CPU rates?
For now this particular function isn't the issue, as it is a background task. I guess I will just have to do some additional monitoring on this.