This project has moved. For the latest updates, please go here.

Scaling V8

Aug 15, 2014 at 9:46 PM
Edited Aug 15, 2014 at 9:47 PM
Hi Again,

I am working on a project which would require a lot separate javascript execution contexts.
Right now I am using V8 Runtime and am creating multiple engines inside it for each JS Execution context. But this scales very poorly.

25000 Engines divided across 25 runtimes take up 11GB of memory. (Jurassic execution engine takes 9GB for 50000 engines, however I switched to Clearscript V8 because of richer .Net support and better performance, but now I want to scale with this performance as well)

Is there a way I can have multiple js contexts within a single engine (something like V8 isolates?)?
Or what are other ways to reduce the memory usage?

Thanks,
Shrainik
Coordinator
Aug 17, 2014 at 8:39 PM
Hi Shrainik,

25000 Engines divided across 25 runtimes take up 11GB of memory.

We've reproduced these numbers using a trivial native test program (no .NET, no ClearScript), so V8's implementation appears to be the cause.

Since V8 runtimes don't support concurrent access, why keep a large number of engines (per runtime) in memory? If you're using them just to hold data, it might make sense to use regular data structures instead, moving data into a script engine only when necessary for script execution.

Is there a way I can have multiple js contexts within a single engine (something like V8 isolates?)?

ClearScript's V8 runtimes are based on V8 isolates, and they're quite expensive. A reasonable guideline for server applications is that you create one per pool thread, or roughly one per CPU core.

In any case, if you're in control of the scripts you run and can ensure that they're well-behaved, you should be able to simulate multiple contexts by adopting simple rules about how data within the engine is organized and shared.

Or what are other ways to reduce the memory usage?

Holding fewer engines in memory is your best bet.

Good luck!