Remote Execution Priority¶
Steps to enable and use remote execution priorities.
Why set the Remote Execution Priority?¶
"Remote Execution Priority" is a feature that can speed up your most time-critical builds.
When using remote build execution, sometimes the incoming execution load may be higher than the number of available executors. This means not all actions can be executed in parallel and some actions are queued.
By default, actions are dequeued and handled on a first come first served basis. However, this may not always be the desired behavior. Some invocations may be more time-critical than others.
Remote Execution Priority is a mechanism to specify which executions should be expedited when there is queueing.
EngFlow implements this feature as follows: we create priority queues for each worker pool. When a pool has a free executor, the action with the highest priority is dequeued and executed. Within the same priority, actions are executed on a first come first served basis, i.e., the oldest entry is dequeued and executed first.
The effect: invocations with a higher priority will be queued less, or not at all, and thus complete faster.
For guidance on which priorities to use, check our blog post.
How to use this feature¶
To use Remote Execution Priorities, enable it both on the server side (EngFlow RE Service) and on the client side.
Server-side requirements¶
The priority values accepted by the cluster are configured via the flag --priority_range. The range must include 0, as this is the default value set by Bazel.
To view the current flag settings: Visit
https://<cluster_name>.cluster.engflow.com/restatus replacing <cluster_name> with
the name of your cluster. Expand the Options section.
Client-side requirements¶
To set the priority of a Bazel invocation, use --remote_execution_priority. Note that higher values indicate higher priority. If unset, the priority defaults to 0.
If a value outside of the server-side configured range is used, the Bazel invocation will fail. The error message returned will include the range the cluster supports, e.g. for a server configuration of --priority_range=-5,5: