stackoverflow is not as helpful as it seems hmm

How long can a worker run before it time outs?

Theoretically indefinitely, though after 30 seconds, it has a higher chance of spontaneous eviction

30s sounds short.

So it is not suitable for long lasting connections

Where do you get this 30s from or is that personal experience?

From some engineers I've talked to. Trying to figure out if it is on the docs.

Here we go:

Is this for some kind of database connection?

They say durable objects can do long connections and ws ?

Yes. First of all because every time it receives a WebSocket event the timer resets, but also because again, you aren't force-evicted after 30 seconds, you just have a higher chance of it occuring.

Does that mean, a normal worker can actually do the same thing if there is no cpu time limit ?

Yes. A normal Worker can run for multiple minutes, though we recommend structuring your app in a way it can recover gracefully if the Worker is spontaneously aborted after the 30 seconds have elapsed.

So what about DO, would it handle long connections better ?

In terms of just the connection, not specifically. One benefit of a DO though is the fact that, if you are running a job over a WebSocket(as an example), and it may take minutes/hours to respond, you can ping to periodically wake it up with DO Alarms, and store any connection-specific state in DO Storage.

Thanks for the knowledge. It is surprising to know that a normal worker can be indeed good.

And maybe

A Durable Object is given 30 seconds of additional CPU time for every request it processes, including WebSocket messages.

Every incoming message brings and extra 30s CPU time..

Is there a way to increase the CPU limits? 🫠 Can I pay extra, I'm already on a Pay-as-you-go plan.

I'm hitting these limits. I reduced the CPU limit errors from > 500 to 1-2 but still, it should be 0.

Bundled has 50ms and Unbound has 30 seconds

I'm not aware of anything higher than that

maybe, divide individual computation into small pieces ?

That 50ms must be per-request ya ?

Yes, it's one big call, which internally makes calls to KV and 3 third-party APIs.

But the thing is not what it calls, it is the huge amount of computation is it

May I ask

oh, I have a weird logic with while loop. let me check that, maybe it's infinitely getting called

"mechanism in the Workers runtime that allows rollover CPU time for requests below the CPU limit"