本頁面說明如何使用永久工作站、優點、要求及 瞭解工作站對沙箱的影響。
永久工作站是 Bazel 伺服器啟動的長時間執行程序，
函式做為實際工具 (通常是編譯器) 的包裝函式，或者
工具本身。為了受益於持續性工作站，工具必須
支援執行一系列編譯，且包裝函式必須
工具 API 和下述的要求/回應格式之間。維持不變
系統在呼叫 worker 時，可能會使用及不使用 --persistent_worker 旗標的
而且負責以適當方式開始與
以及在結束時關閉 worker每個 worker 例項都會指派 (但不會以 chroot 指派) <outputBase>/bazel-workers 底下的獨立工作目錄。
使用永久工作站 執行策略， 啟動負擔、增加 JIT 編譯，並啟用快取 範例。這項策略會向長時間執行的程序傳送多個要求，進而達成這些改善。
永久工作站適用於多種語言，包括 Java、 Scala、 Kotlin 等等。
使用 NodeJS 執行階段的程式可使用 @bazel/worker 輔助程式庫 實作工作站通訊協定
使用持續性 worker
Bazel 0.27 以上版本預設會在執行建構作業時使用持續性工作站，但遠端執行作業會優先執行。如果動作不支援永續性工作站，Bazel 會改為為每個動作啟動工具例項。您可以為適用的工具助憶法設定 worker 策略，明確設定建構作業使用持續性工作站。最佳做法是將 local 指定為
回 worker 策略：
bazel build //my:target --strategy=Javac=worker,local
使用 worker 策略取代本機策略，可提高編譯速度 速度會明顯變快，視導入方式而定對於 Java，建構作業的速度可加快 2 至 4 倍，漸進式編譯的速度則可能更快。編譯 Bazel 是 速度幾乎是工作人員的 2.5 倍詳情請參閱 「選擇工作站數量」專區。
如果您也有與本機建構環境相符的遠端建構環境，可以使用實驗性的動態策略，以便同時執行遠端執行作業和 worker 執行作業。如要啟用動態策略，請傳遞 --experimental_spawn_scheduler 標記。這項策略會自動啟用 worker，因此您不需要指定 worker 策略，但仍可使用 local 或 sandboxed 做為備用。
選擇工作站數量
每個助憶法的工作站執行個體預設數量為 4，但可以使用 worker_max_instances 標記進行調整。兩者之間有何權衡取捨
並獲得 JIT 編譯和快取命中的數量。員工人數越多，就可獲得更多
目標將支付執行非 JIT 程式碼的啟動成本，以及冷到
快取。如果您要建構的目標數量不多，單一工作站可能會在編譯速度和資源使用量之間取得最佳平衡 (例如，請參閱 問題 #8586)。worker_max_instances 標記會設定每個助記符和標記集的 worker 例項數量上限 (請參閱下方說明)，因此在混合系統中，如果您保留預設值，可能會使用大量記憶體。如果是漸進式建構作業
使用多個工作站執行個體
就能享有更小的優勢
這張圖表顯示在 6 核心超執行緒 Intel Xeon 3.5 GHz Linux 工作站 (64 GB RAM) 上，Bazel (目標 //src:bazel) 從頭開始編譯的時間。針對每個 worker 設定，系統會執行五次清除建構作業，並取最後四次的平均值。
圖 1. 清理建構作業的效能改善圖表。
針對這項設定，兩個工作站的編譯速度最快，但只有 14% 與一個工作站相比。如果需要 減少記憶體用量
增量編譯通常更有益。清除建構作業相對少見，但在編譯之間變更單一檔案的情況很常見，特別是在以測試為導向的開發作業中。上述範例也有一些非 Java 項目 並包裝動作來覆蓋漸進式編譯時間。
僅重新編譯 Java 來源
(//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar)
但每次變更
AbstractContainerizingSandboxedSpawn.java
速度可達 3 倍 (平均有 20 個暖身版本，執行版本平均為 20 個漸進式版本)
已捨棄)：
圖 2. 漸進式建構的效能改善圖表。
速度提升幅度取決於所做的變更。因此 6 的載入速度 是在上述常用常數發生變更時觸發。
修改持續性 worker
您可以將
--worker_extra_flag
旗標，用於對工作站指定啟動標記，並以助憶鍵為索引鍵。舉例來說：
傳遞 --worker_extra_flag=javac=--debug 只會開啟 Javac 偵錯。
每次使用此標記時，只能設定一個工作站旗標，而且一次只能設定一個記憶式。
不僅可以為每個記憶式個別建立工作站，
初始化標記中的變化版本。每個助憶法和啟動旗標組合都會合併為 WorkerKey，且每個 WorkerKey 最多可建立 worker_max_instances 個 worker。請參閱下一節，瞭解動作設定如何指定設定標記。
您可以使用
--high_priority_workers
標記，指定要按一般優先度優先執行的記憶法
助憶鍵這麼做有助於將一律位於重要路徑中的動作設為優先。如果有兩個或更多高優先順序的 worker 執行要求，系統會禁止所有其他 worker 執行。這個標記可重複使用。
傳遞 --worker_sandboxing 標記，可讓每個 worker 要求為所有輸入內容使用專屬的沙箱目錄。設定沙箱需要一點時間，
尤其是在 macOS 上，但提供更好的正確性保證。
--worker_quit_after_build 標記主要用於偵錯和剖析。此標記會在建構作業完成後，強制所有工作者離開。您也可以
--worker_verbose 到
取得更多 worker 作業相關資訊這個標記反映在
WorkRequest 中的 verbosity 欄位，可讓工作站實作
更詳細。
工作站會將記錄儲存在 <outputBase>/bazel-workers 目錄中，例如 /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log。檔案名稱包含 worker ID 和 mnemonic。由於
每增加一次 WorkerKey，你可能會看到超過 worker_max_instances
特定記憶的記錄檔
如需 Android 版本的詳細資訊，請參閱 Android「Build Performance」(Android 建構效能) 頁面。
實作持續性 worker
詳情請參閱「建立永久工作站」頁面 瞭解如何設定工作站。
下方範例為使用 JSON 的工作站，顯示 Starlark 設定：
args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
output = args_file,
content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
mnemonic = "SomeCompiler",
executable = "bin/some_compiler_wrapper",
inputs = inputs,
outputs = outputs,
arguments = [ "-max_mem=4G", "@%s" % args_file.path],
execution_requirements = {
"supports-workers" : "1", "requires-worker-protocol" : "json" }
)
根據這個定義，第一次使用這個動作時，系統會先執行指令列 /bin/some_compiler -max_mem=4G --persistent_worker。要求
編譯 Foo.java 後看起來會像這樣：
注意：雖然通訊協定緩衝區規格使用「駝峰式大小寫」(request_id)，但 JSON 通訊協定則使用「駝峰式大小寫」(requestId)。在本文件中，我們會在 JSON 範例中使用駝峰式大小寫，但在討論欄位時，無論通訊協定為何，都會使用駝峰式大小寫。
{
"arguments": [ "-g", "-source", "1.5", "Foo.java" ]
"inputs": [
{ "path": "symlinkfarm/input1", "digest": "d49a..." },
{ "path": "symlinkfarm/input2", "digest": "093d..." },
],
}
工作者會以 JSON (以換行符號分隔) 格式 (因為 requires-worker-protocol 已設為 JSON) 在 stdin 上接收此資料。接著，worker 會執行動作，並透過 stdout 將 JSON 格式的 WorkResponse 傳送至 Bazel。Bazel，然後
剖析此回應，然後手動將其轉換為 WorkResponse proto。目的地：
使用二進位編碼的 protobuf 來與相關聯的工作站通訊
JSON，requires-worker-protocol 會設為 proto，如下所示：
execution_requirements = {
"supports-workers" : "1" ,
"requires-worker-protocol" : "proto"
}
如果您未在執行要求中加入 requires-worker-protocol，Bazel 會預設使用 protobuf 的 worker 通訊。
Bazel 會從助憶鍵和共用標記衍生出 WorkerKey，因此如有
設定允許變更 max_mem 參數，其他工作站
。如果使用太多變化版本，可能會導致記憶體用量過多。
每個工作站目前一次只能處理一項要求。實驗功能 多工工作站功能可讓您 執行緒，前提是基礎工具為多執行緒，且包裝函式設定為 瞭解這點
於 這個 GitHub 存放區 您可以看到使用 Java 和 Python 編寫的工作站包裝函式範例。如果發生以下情況： 是透過 JavaScript 或 TypeScript 運作 @bazel/worker 套件 和 nodejs 工作站範例 可能會有幫助
工作站對沙箱有何影響？
根據預設，使用 worker 策略不會在沙箱中執行動作，這與 local 策略類似。您可以設定
--worker_sandboxing 標記，用於在沙箱內執行所有工作站，確保每個
執行此工具時，只會看見該工具應有的輸入檔案。工具
仍可能會在內部要求之間洩漏資訊，例如透過
快取。使用 dynamic 策略時，必須將 worker 置於沙箱中。
為了讓工作站正確使用編譯器快取，系統會傳送摘要 為每個輸入檔案建立容器因此，編譯器或包裝函式可以檢查輸入內容是否仍有效，而無須讀取檔案。
即使使用輸入摘要來防範不必要的快取，沙箱化工作站提供的沙箱功能，也比純沙箱功能較不嚴格，因為該工具可能會保留先前要求影響的其他內部狀態。
只有在 worker 實作支援的情況下，才能啟用多重廣告工作站的沙箱機制，
而且，您必須透過
--experimental_worker_multiplex_sandboxing 標記。詳情請參閱設計文件。
延伸閱讀
如要進一步瞭解持續性工作站，請參閱：