Documentation Request: More info about the role of the server vs the worker about bazel-buildfarm

[thelgevold]

I am currently using the following approach to spin up multiple workers per server: thelgevold@52e70e1

[werkt]

The memory reference implementation is designed to be single-host-server, multiple-host-workers. The Workers can be configured to schedule multiple concurrent executions (

bazel-buildfarm/examples/worker.config.example

Line 102 in d4fefa0

execute_stage_width: 1

) and benefits greatly from a single worker monopolizing a host to the cache coherency of its backing CASFileCache (

bazel-buildfarm/examples/worker.config.example

Lines 34 to 38 in d4fefa0

	# all content for the operations will be stored under this path
	root: "/tmp/worker"
	# the local cache location relative to the 'root', or absolute
	cas_cache_directory: "cache"

). Expanding the concurrent cpu utilization is vastly preferred to trying to run isolated workers on a single host, due to the shared cache of inputs (great way to tap out your bandwidth and duplicate your efforts).

I have run this configuration with the memory server and operationqueue worker across 1000s of cores, and successfully leveraged all of them (https://github.com/werkt/bazel-stress was used at bazelcon with this setup).

[thelgevold]

@werkt Thanks for clarifying this. I noticed a big performance improvement from switching to this approach.

Thanks again!

[thelgevold]

I did a quick write-up of the experiment I ran. Sharing in case anyone is interested: http://www.syntaxsuccess.com/viewarticle/bazel-remote-execution

[werkt]

Closing this out, as I believe all of the questions have been answered.