I'm aware of the issue, and I'm also aware of how my original understanding was flawed (see the issue on GitHub). I originally thought that there were multiple containers running concurrently, one for each crate being documented, but that isn't the case; there is currently one container running at a time.
That said, if and only if the docs team thinks it's worth the effort, we can combine approaches to solve the various issues:
- All crates that are owned by the same entity are built within the same container. Within a given container crates can be built either concurrently or serially, it doesn't really matter which.
- Containers are ephemeral; when the last build process completes, the container is disposed of in the same manner that they are disposed of currently (I don't know how that's currently handled, which is why I'm hand waving it away). That said, if a given owner is manually pushing crates (so that there is reasonably large period of time between publications to crates.io), and their associated container is still alive, docs.rs will push the build request to their currently living container and not spin up a new one.
- Containers are executed concurrently, and have their relative CPU shares adjusted according the algorithm I gave above.
The trick is that if a given owner publishes multiple crates at once, and docs.rs is running a container for that owner already, then the build request is passed to the currently running container to process. Since the container isn't terminated until after the last build process completes, it will get progressively less CPU to execute, which will slow a given owner's crates down without affecting other owners. Once the container has executed all build processes, it can be allowed to die naturally. If the owner publishes another crate after their container shutdown, then a new container is spun up, with the default CPU share. That way no one is permanently punished, but if you are taking up resources (either because you have a lot of small crates, or one gargantuan one), you only affect your own crates, rather than everyone else's.
Note that the outlined method won't work as docs.rs is currently set up. Since it only executes a single container at a time, adjusting the relative CPU share is meaningless. So before this method could be applied, a great deal of work would need to be done to change the entire architecture. And as @pietroalbini has already said in the other thread, this is pretty much a non-issue for the docs team. In short, I'm 99.99% sure that we are now beating a dead horse 