pctx scalability issues with large number of mcp servers / tools

[repl-samuel]

Help!

I was very happy with pctx before running into a scalabilty issue.

I am doing a POC that connect pctx process server and registered 38 MCP servers overall 500+ tools.
pctx server working fine with low concurrency,
when concurrency increase to over 5, it lags a log.
from pctx logs, it looks every tool call comes with a huge payload (tool descriptions?) before it, the console just kept scrolling. I wonder if that's related to the lag the issue, or can you point me a direction to look into? anything I can provide?

[repl-samuel]

running pctx server with RUST_LOG=error suppress the logs in console, but it didn't resolve the lag issue with higher concurrency.
it looks there might be a bottleneck somewhere?

[repl-samuel]

wild guess, It feels the /execute_typescript calls may be serialized?

[repl-samuel]

pctx_executor/src/lib.rs:24-27

static V8_MUTEX: std::sync::LazyLock<Mutex<()>> = std::sync::LazyLock::new(|| {
    init_v8_platform();
    Mutex::new(())
});

Every call to execute() acquires this mutex at line 134 and holds it for the entire duration — type checking + code execution. This is a single process-wide queue, so all concurrent /execute_typescript requests run strictly sequentially.

The comment explains the constraint: V8 isolates share platform-level state (code pages, thread pool, GC metadata) that isn't safe to access concurrently from multiple OS threads.

[eliasposen]

@repl-samuel you are exactly right. This is a deno limitation that each process can only have one JSRuntime executing at a given point. We are exploring different solutions for scalability between devops and in-code fixes

[repl-samuel]

#72
please review
Disclosure: I am not a rust expert and I used coding assistant to help write the code. I reviewed the code from conceptual level and have verified it working in my previous setup, and the server logs are clean. Plesae do take closer look of the code.