[kentonv]

Yes. Currently you get at most 50ms CPU time per request, and memory usage of your Javascript VM is limited to 128MB. These numbers may change before launch.

In practice, though, a typical script probably uses much less than 1ms of CPU time per request and probably needs only a couple megs of RAM. Because we're applying limits on the level of a V8 Isolate, not on an OS process, the limits go a lot further.

Keep in mind that Cloudflare Workers are not intended to be a place where you do "bulk compute", but rather where you run little bits of code that benefit from being close to users.

[eloff]

I would very much like to see a pay-as-you-go cloud pricing model that allows you to pay to go over these limits (within reason.) For the use case I'm envisaging, filtering largish buffers of Cap'N Proto data (I'm tickled that both of these things are your babies!) I can use streaming fetch API to stay within the memory limit, but the 50ms limit would really be a hard wall that would cause requests to fail on larger amounts of data. I'd be happy to pay in those cases for extra execution time.

[kentonv]

I'd love to hear more about your use case (especially since it involves Cap'n Proto!). E-mail me? (kenton at cloudflare)

[jamesrwhite]

Thanks, I should have specified I meant in comparison to Lambda@Edge on CloudFront which this seems quite similar in terms of the use cases.

[corobo]

What happens if the limits are reached? Does the end user get an error or does the request proceed as it would without the script?

[kentonv]

Currently, an error, because default handling might not be correct in many cases -- imagine a script implementing access control or expanding an HTML template. But I'd be open to the idea of letting the script call, like, `event.fallbackOk()` upfront to specify that default behavior as a fallback is safe.

Note that the 50ms is CPU time, not wall time. This is actually a pretty huge amount of time for handling one request.