You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
computer: raise the JavaScript backend default limits
The starting defaults were tuned conservatively and proved too tight in
practice. Raise the execution timeout ceiling to three minutes and the
default to sixty seconds, the source and input byte ceilings to one
mebibyte each, the retention window to sixty minutes, the concurrent
execution ceiling to twenty-four, and the concurrent capability call
ceiling to thirty-two. Update the backend documentation to match and
keep the concurrency-cap test pinned to a single execution so it still
exercises the ceiling.
Copy file name to clipboardExpand all lines: docs/17_isolate_javascript.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,8 +14,8 @@ const workspace = new Workspace({
14
14
loader: env.LOADER,
15
15
root: "/workspace",
16
16
access: "read-write",
17
-
defaultTimeoutMs: 10_000,
18
-
maxTimeoutMs: 30_000,
17
+
defaultTimeoutMs: 60_000,
18
+
maxTimeoutMs: 180_000,
19
19
globalOutbound: null,
20
20
modules: {
21
21
"math-kit": `export const double = value => value * 2;`,
@@ -81,11 +81,11 @@ Workspace parses the graph before loading the Worker, confines every durable pat
81
81
82
82
## Execution limits and retention
83
83
84
-
The backend admits one execution at a time by default. A concurrent start fails with `EEXEC_BUSY` instead of creating an unbounded number of Dynamic Workers. Set`maxConcurrentExecutions` only after measuring the Durable Object and Worker Loader limits for the deployment.
84
+
The backend admits up to twenty-four executions at a time by default. A concurrent start past that ceiling fails with `EEXEC_BUSY` instead of creating an unbounded number of Dynamic Workers. Adjust`maxConcurrentExecutions` after measuring the Durable Object and Worker Loader limits for the deployment.
85
85
86
86
Each execution also bounds log events, active event subscribers, directory entries per read, concurrent and total capability calls, and cumulative capability request and response bytes. The corresponding `maxLogEvents`, `maxExecutionSubscribers`, `maxDirectoryEntries`, and `max*Capability*` options may be lowered for public workloads. Directory reads apply their limit in SQLite before materializing rows. Requests are checked inside the isolate before Workers RPC and again by the host.
87
87
88
-
Completed execution records remain available for replay for five minutes by default. The backend also keeps at most 100 completed records. Configure these bounds with `retentionMs` and `maxRetainedExecutions`. Completed records leave the in-memory active set immediately; replay reads them from SQLite.
88
+
Completed execution records remain available for replay for sixty minutes by default. The backend also keeps at most 100 completed records. Configure these bounds with `retentionMs` and `maxRetainedExecutions`. Completed records leave the in-memory active set immediately; replay reads them from SQLite.
89
89
90
90
Cancellation stops new host capability calls, disposes the Dynamic Worker, and waits for host calls that were already accepted. Exit 130 is published only after those calls settle. Normal completion uses the same drain rule, so an unawaited capability call cannot mutate the workspace after exit 0.
0 commit comments