- 適用於 JDK 23 的 GraalVM (最新版)
- 適用於 JDK 24 的 GraalVM (搶先體驗版)
- 適用於 JDK 21 的 GraalVM
- 適用於 JDK 17 的 GraalVM
- 封存
- 開發組建
常見問題
我可以使用單元測試進行分析嗎? #
是的,這是可行的,但通常不建議。若要使用單元測試產生設定檔,您應該為您的測試套件產生一個儀器化的二進位檔,就像您為任何應用程式產生原生可執行檔一樣。例如,您可以有一個啟動測試工具的 main()
方法。一旦儀器化的二進位檔執行,它將會像任何儀器化的二進位檔一樣,轉儲包含設定檔的檔案。
請注意,設定檔引導最佳化的品質取決於您作為最佳化原生組建輸入所提供的設定檔品質。您應該確保您的測試能準確呈現在生產環境中執行的工作負載。一般而言,很難保證這一點,因為
- 單元測試旨在測試元件的所有邊角案例,其中許多在實務中並不常見(換句話說,雖然它們需要被測試並正確運作,但您程式碼中的邊角案例通常不需要快速)。
- 您的程式碼的不同元件並非總是使用相同數量的單元測試來呈現。基於單元測試套件的設定檔可能會過度呈現一個元件的重要性,而低估其他元件的重要性。
- 單元測試套件會隨著時間的推移而演變,隨著越來越多的測試被添加進來。今天可能準確呈現您應用程式行為的內容,明天可能就無法準確呈現。
例如,您正在實作一個提供靜態內容的網路伺服器。大部分時間,網路伺服器將會從磁碟或記憶體快取中讀取檔案、壓縮該檔案,然後透過網路傳送壓縮的位元組。然而,一個好的單元測試套件將會測試網路伺服器的所有元件,包括用於組態檔剖析、快取失效或遠端除錯的程式碼,這些程式碼在網路伺服器的典型執行期間可能會很少執行或根本不執行。如果您收集所有單元測試的設定檔,它們將會過度呈現在實務中很少執行的程式碼部分,並以此方式誤導編譯器最佳化。
總之,雖然這是可行的,但我們不建議使用單元測試作為設定檔,因為不清楚它們如何能代表應用程式的運作方式。我們建議的做法是
- 識別代表重要生產工作負載的端對端測試子集。端對端測試模擬您的應用程式在生產環境中的運作方式,並且更有可能正確描述程式碼中時間花費的方式和位置。在先前的網路伺服器範例中,端對端測試將會啟動網路伺服器,傳送數千個請求以擷取各種 URL,然後關閉伺服器。
- 或者,建立一個代表您的應用程式在生產環境中運作方式的基準工作負載。一個好的基準測試將會包含典型工作負載的特性。在先前的網路伺服器範例中,一個真實的基準測試將會包含在網路伺服器在生產環境中執行時所觀察到的請求分佈。也就是說,基準測試將會模擬在生產環境中請求特定大小檔案的頻率,以及檔案的壓縮率。
PGO 設定檔是否具有足夠的跨平台性,還是應該單獨為每個目標進行儀器化? #
是的,在大多數情況下,PGO 設定檔具有足夠的跨平台性。您可以透過在一個平台上執行儀器化的二進位檔來收集設定檔,然後使用這些設定檔在不同的平台上建立最佳化的原生可執行檔。
在某些情況下,原生映像會根據組建二進位檔的平台而使用不同的類別和方法。例如,PosixProcessPropertiesSupport
類別包含在基於 POSIX 的系統上操作程式的程式碼,而 WindowsProcessPropertiesSupport
類別包含在 Windows 上操作程式的程式碼。同樣地,JDK 的某些部分包含平台特定的程式碼。在這些情況下,設定檔將會包含一個平台的條目,但最佳化的原生組建將不會找到其平台特定程式碼的設定檔條目。這些邊角案例很少見,通常不會對效能產生影響,但這是需要注意的事情。
總之,最佳做法始終是在與最佳化原生可執行檔的目標相同的平台上收集設定檔。然而,使用在不同平台上收集的設定檔通常應該能正常運作。
如果程式碼變更有限,是否可以重複使用分析資訊,還是需要為每個組建收集新的分析資訊? #
是的,分析資訊始終可以重複使用,並且必須正確產生原生可執行檔。沒有必要為每個組建收集新的分析資訊。
但是請注意,最佳化原生可執行檔的效能影響取決於設定檔的品質。如果程式的新程式碼與收集設定檔的程式碼差異很大,則編譯器最佳化將會誤導有關哪些程式碼很重要的資訊。如果程式碼變更足夠小,或僅限於程式的冷部分,則使用舊設定檔通常不會影響最佳化原生二進位檔的效能。
請閱讀追蹤設定檔品質指南,以深入瞭解此主題。
我也可以使用儀器化的二進位檔執行基準測試嗎? #
是的,可以為任何程式(包括基準測試)產生儀器化的二進位檔。實際上,使用代表性的基準測試來收集設定檔是收集設定檔的建議方式。
請注意,儀器化開銷通常會使儀器化的二進位檔比預設(未儀器化)的原生可執行檔慢。雖然我們不斷努力將儀器化的開銷降至最低,但您可能會注意到儀器化的二進位檔速度較慢,而您的效能將會因您正在執行的應用程式中的程式碼模式而異。
此外,請注意,基準測試最好能代表您在生產環境中預期的工作負載。基準測試的工作負載與生產工作負載越一致,PGO 就越有可能對最佳化的原生組建產生正面的效能影響。
總之,如果基準測試準確地代表您將在生產環境中執行的工作負載,那麼最好在儀器化的基準測試二進位檔上收集設定檔,然後使用這些設定檔來為您的生產工作負載建立最佳化的原生可執行檔。
GraalVM 如何產生用於分析網路應用程式的負載? #
GraalVM 本身不會產生用於分析使用原生映像編譯的網路應用程式的負載。相反地,您需要使用負載測試工具來產生負載。
例如,如果您的網路應用程式公開了數個 HTTP 端點,那麼您需要使用像是 wrk
的負載測試工具來產生傳送到這些 HTTP 端點的請求串流。此設定將如下所示:您組建一個儀器化的網路應用程式二進位檔,在一個程序中啟動它,並在另一個程序中啟動像是 wrk
的負載測試工具。負載測試的持續時間需要足夠長,才能執行網路應用程式中最常被生產使用者存取的端點,並使用您預期在生產環境中會遇到的請求酬載。對於簡單的網路應用程式,1 分鐘的持續時間通常足以產生良好品質的設定檔(但這取決於您的特定應用程式)。在負載測試完成且網路應用程式結束後,它將會將設定檔轉儲到檔案。
為什麼不在生產環境中收集設定檔一段時間?例如,僅在星期一的 8:00 到 12:00 在服務的一個執行個體上收集? #
是的,這是收集設定檔的好方法。
儀器化的二進位檔具有一定的開銷,這取決於特定應用程式中的程式碼模式。然而,如果只有一個執行個體在特定期間使用儀器化的二進位檔,而您服務的所有其他執行個體都使用正常或 PGO 最佳化的組建,那麼這在實務中通常是可以接受的。
請在追蹤設定檔品質指南中找到有關此主題的更多資訊。