Cloudflare Developers•3y ago

How does worker max time work precisely?

What (I think) I understand:

When using paid plan, you can make use of either Bundled or Unbound worker runtime.
In case of Unbound, the worker can last for a maximum of 30 seconds.
It can serve 6 multiple connections as the same time

What I'm trying to figure out:

If my request takes 25 seconds to process, should I return a response immediately or after those 25 seconds?
How do I prevent a second reqeust from coming in after 5 seconds (at which point there isn't enough time to process the request during max runtime of the worker)?

Most likely my mental model is somehow wrong, would love to learn!

WebberOP•7/8/23, 11:21 PM

Does that mean every user request gets its own worker instance / v8 Isolate for every request?

WebberOP•7/8/23, 11:27 PM

Ok that makes sense.
However I would still like to know how a request that starts after 10 seconds would work. Does it mean the traffic to that worker instance gets rerouted to a new worker, and the request would be fine as long as it also completes in 25 seconds?

WebberOP•7/8/23, 11:27 PM

Or put differently: Am I guaranteed that every request to any (unbound) worker instance will always have 30 seconds to be handled?

WebberOP•7/8/23, 11:29 PM

I see. Very cool

WebberOP•7/8/23, 11:30 PM

So in case of no rollout, but regular use, if I get a request every 5 seconds (and each request still takes 25 seconds to complete), the instance will be longer lived than 30 seconds. Is that also correct?

Unsmart•7/8/23, 11:32 PM

Each instance can last many many hours if it keeps getting requests and it will guarantee every request gets at least 30 seconds to process before they do any evictions. Evictions really only happen for runtime updates and they will spin up a new instance with the new runtime while you have old requests using the old runtime if needed

WebberOP•7/8/23, 11:36 PM

Awesome!

WebberOP•7/8/23, 11:38 PM

One last follow-up question if you don't mind.

In that case, why is

env

env

passed as part of the async fetchasync fetch call?
I realise that after an hour they might be a bit outdated, but is it also possible to load

env

env

manually (e.g. periodically)?

Consider some code like:

app = expressLike(/* some elaborate application that needs `env` */)

export default {
  async fetch(req, env, ctx) {
     app.handle(req)
  }
}

app = expressLike(/* some elaborate application that needs `env` */)

export default {
  async fetch(req, env, ctx) {
     app.handle(req)
  }
}

Is there some good practice in handling env variables in cases like this?

WebberOP•7/8/23, 11:42 PM

Ah right. I forgot.
All the more reason to already have the

env

env

before

fetch

fetch

is called, I'd say - right?

WebberOP•7/8/23, 11:44 PM

Meaning I should define my application routes (as well as any possible class instances) for every request - inside the

fetch

fetch

implementation?

WebberOP•7/8/23, 11:49 PM

I see

WebberOP•7/9/23, 12:09 AM

Thank you very much!

How does worker max time work precisely?

Similar Threads

Similar Threads

Similar Threads