Eliminating cold starts with Cloudflare ...
I just read this article https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers/
Can I get some clarification? If I have a worker that will match on this for example
auth.development.example.com instead of only matching on development.example.com/auth* Cloudflare can improve or eliminate the cold start. Is this correct?
In my case I am using TRPC inside my worker, so it will handle some routing when it recieves the request. Another question is if I follow the first pattern and match that way, can I still use paths as long as they get handled internally in my worker?The Cloudflare Blog
Eliminating cold starts with Cloudflare Workers
A “cold start” is the time it takes to load and execute a new copy of a serverless function for the first time. It’s a problem that’s both complicated to solve and costly to fix.
1 Reply
Initial testing seems to indicate my assumption is correct. Initially my cold start was around 2 second and appears to have gone down to around 300 ms when I eliminate the route. In both cases when the worker is warm, the requests are around 60 ms.
Hmm, maybe not. After 30 minutes, it's back at 2 seconds.
Switching to paid plan doesn't seem to help at all
My bundle size
Total Upload: 3870.40 KiB / gzip: 561.21 KiB
@kian Any ideas that I might try?
I'm still using a path, but have no routes set. All requests to the subdomain should go to this worker.
A little more context. Im testing via a health check endpoint inside my function. My function contains TRPC for routing and the Prisma edge client connected to data-proxy, i'm not hitting routes that go to the database or make external requests. Certainly appears that i'm doing something wrong to get 2.5 second starts on a small simple function(small router).