Decrease time spent waiting for compilation requests

[ffissore]

Have you considered asking the community support in terms of mirroring the playground?
At the moment https://play.rust-lang.org/ takes about ~1.5 secs to compile and run a snippet. Could sharing the load across different VMs make it snappier?

[shepmaster]

As of right now, the load average is 0.99, 0.86, 0.86, so the machine is pretty much right at where it should be. I don't believe I have any longer-term stats handy.

community support

The EC2 instance provided by Mozilla is 2x2.30GHz with 8GB of RAM, so it's not a tiny machine.

Could sharing the load across different VMs make it snappier?

It's possible, but would require deeper digging to determine what the problem really is.

For example, the alternate deployment (https://play.integer32.com/) has a load average of 0.05, 0.09, 0.04, but is a 1x2.40GHz with 1GB of RAM, and compiling takes the same amount of time (1.14s vs 1.19s, measured via Chrome's network inspector).

This may mean that the performance bottleneck is mostly centered around disk access.

[ffissore]

I've just run the playground on my machine (kind of beefy i7 with 32 gb of ram) and the hello world snippet takes ~1.3 secs, so I've reproduced the issue locally. I'll try to investigate

[ffissore]

It looks like the root cause is docker. Starting a temporary container takes ~1sec, regardless of the container and the command you run (try time docker run --rm ubuntu:18.04 whoami). Then there's the time taken by cargo.

Only idea that comes to my mind is this.
We start only one container at playground start up time, and have a server running inside the container. Such server exposes an /execute API that:

1. makes a copy of the current playground folder into a temporary folder
2. stores the snippet into src/main.rs
3. calls modify-cargo-toml on the temporary cargo folder
4. runs cargo build/run/whatever
5. deletes the temporary folder

Drawbacks are:

1. an "evil" snippet could list the currently running snippets
2. in order to call the server running inside docker, we need to give network capabilities to it and therefore to the snippets

I'm not linux security expert but maybe the cap params currently provided to docker have to be relaxed as well in order to run such server, and this could then lead to more issues

[ffissore]

One possible solution to drawback 2 is to run cargo through firejail (which I've just discovered, so I'm no expert), which has a --net=none param

[ffissore]

I've tried and failed to implement the solution above.
For the record, instead of making another server listening from inside the docker container, I've interacted with it through docker exec and cp commands
It worked until I hit a wall:

• once the contents of /playground are copied into a temp folder, cargo thinks they have to be recompiled, thus wasting time (and btw some fail to compile too)
• /playground is 1.1G, so making many copies of it is not a good idea

Should you want to take a look at the diff, it's here ffissore@d181e9a

[shepmaster]

Starting a temporary container takes ~1sec, regardless of the container and the command you run

FWIW, I think this is predicated on disk speed:

$ time docker run --rm ubuntu:18.04 whoami
root

real	0m0.319s
user	0m0.048s
sys	0m0.025s

[shepmaster]

I'm going to reopen this just to keep track of ways of improving the speed; it's certainly something we'd like!