剖析概念
剖析是一種動態程式碼分析作業。您可以擷取應用程式執行時的特性，然後利用這些資訊找出如何讓應用程式更快、更有效率。
以往，只有在應用程式開發期間才會執行分析。這種方法需要能夠開發可準確預測實際工作環境的工作負載測試和基準。
「持續剖析」是指在實際工作環境中執行應用程式時進行剖析。這種做法可免除為正式上線環境開發準確的預測負載測試和基準測試的必要性。持續剖析的研究顯示，這項技術準確且具有成本效益*。
Cloud Profiler 是專為在 Google Cloud上執行的應用程式設計的持續剖析工具：
這是一種統計型 (或取樣型) 分析器，具有低負載，且適合用於正式環境。
支援常見語言，並收集多種剖析資料類型。如需概略說明，請參閱「可用的剖析類型」。
設定 Google Cloud 應用程式以產生設定檔資料，是簡單的一次性程序：連結或執行服務，並納入剖析代理程式。應用程式部署完成後，剖析代理程式會定期執行，收集成效資料，然後將資料傳送至您的 Google Cloud 專案。如要進一步瞭解這項程序，請參閱「剖析資料收集」。
收集應用程式的剖析資料後，您可以使用 Profiler 介面分析資料。分析設定檔資料通常是重複進行的程序，這取決於您對應用程式設計及其程式設計語言的瞭解程度。
*請參閱以下 Google 全公司剖析：資料中心的持續剖析基礎架構 和 持續剖析：週期都到哪去了？。
可用的剖析類型
下表總結了支援的剖析類型：
| 設定檔類型 | Go | Java | Node.js | Python |
|---|---|---|---|---|
| CPU 作業時間 | 有 | Y | 有 | |
| 堆積 | 有 | Y | 有 | |
| 分配的堆積 | 有 | |||
| [Contention] (爭用情況) | 有 | |||
| [Threads] (執行緒) | 有 | |||
| 實際時間 | 有 | Y | 是 |
本節的其餘部分將詳細說明每種設定檔類型。
時間計算
CPU 時間是指 CPU 花費在執行程式碼區塊的時間。
函式的 CPU 時間能讓您知道 CPU 執行指令的時間長度。但不會計入 CPU 等候或處理其他指令的時間。
時鐘時間 (又稱為「實際時間」) 是指執行一個程式碼區塊所需的時間。
函式的時鐘時間是計算從進入到離開函式所經歷的時間，時鐘時間包含所有等待時間，包括鎖定和執行緒同步處理的等待時間。理論上，程式碼區塊的實際時間一定會比 CPU 時間長。
如果實際時間值長於 CPU 時間，表示程式碼花費了等待時間。如果差異相當大，應用程式可能會有資源瓶頸。
如果 CPU 時間與實際時間相近，表示程式碼 CPU 密集度高，幾乎所有執行時間都由 CPU 消耗。長時間執行的 CPU 密集程式碼區塊可能是最佳化候選項目。
堆積 (記憶體) 用量
堆積用量 (又稱為「堆積」) 是指在收集剖析資料時，在程式的堆積中分配到的記憶體大小。與其他剖析類型不同，這類型會在單一時間點收集堆積使用量。
堆積分配量 (又稱為「分配的堆積」) 是指在收集剖析資料的間隔期間，在程式的堆積中分配到的記憶體總和大小。這個值包含已分配、已釋放且不再使用的記憶體。舉例來說，請考慮重複執行下列順序的工作：分配 1 MiB、等待 500 毫秒、釋放 1 MiB、等待 500 毫秒。在收集分配堆積剖析資料的 10 秒內，有 10 個分配和 10 個釋放。這個設定檔會顯示 10 MiB 的已分配堆積，因為系統不會考慮釋放。平均分配率為 10 MiB/10 秒，即每秒 1 MiB。
剖析堆積使用量可協助您發現程式中潛在的效率低落及記憶體流失狀況。剖析堆積分配量可協助您掌握哪些分配項目會為垃圾收集器帶來最多工作。
執行緒資訊
建立執行緒的應用程式可能會遇到執行緒遭封鎖和執行緒流失的問題：
- 已封鎖的執行緒是指已建立但正在等待鎖定的執行緒。這些執行緒目前並未執行，也可能永遠不會執行。不過，封鎖的執行緒可能會在最後執行。
- 當建立的執行緒數量不斷增加時，就會發生執行緒流失。
封鎖的執行緒是導致執行緒外洩的其中一個原因。
在影格層級，執行緒設定檔會顯示包含該影格的執行緒平均數量。這個設定檔類型會在單一時間點收集執行緒使用量。
爭用情況
在多執行緒程式中，等待共用資源存取權序列化可能會佔用大量時間。瞭解爭用行為可協助引導程式碼設計，並掌握可用於調整效能的資訊。
收集剖析資料
Profiler 代理程式的作用是從應用程式擷取剖析資料，然後使用 Profiler API 將這些資料傳輸至 Profiler 後端。每組剖析資料僅適用於單一應用程式執行個體，其中包含四個可識別其部署項目的欄位：
- Google Cloud 專案
- 應用程式名稱
- 應用程式區
- 應用程式版本
代理程式準備好開始擷取剖析資料時，會向 Profiler 後端發出 Profiler API 指令。後端會接收這個要求，然後 (在最簡單的情況下) 立即回覆代理程式。回覆內容會指定要擷取的剖析類型。接著代理程式便會擷取剖析資料並將其傳輸至後端。最後，Profiler 後端會將剖析資料與您的 Google Cloud 專案建立關聯。然後，您便可以使用 Profiler 介面來查看和分析資料。
實際的握手序列比上一段內容所描述的更複雜。舉例來說，當 Profiler 收到代理程式的要求時，後端會檢查其資料庫，判斷先前是否曾收到該代理程式的要求。如果沒有，後端會將代理程式資訊新增至其資料庫中。如果該代理程式的部署項目欄位與任何其他已記錄之代理程式的設定不相符，系統將會建立新的部署項目。
後端平均每分鐘會針對每個部署項目和每個剖析類型選取一個代理程式，並指示代理程式擷取剖析資料。例如，如果部署項目的代理程式支援堆積和實際時間剖析，則平均每分鐘會擷取兩組剖析資料：
對於所有剖析類型 (堆積使用量和執行緒除外)，一組剖析資料代表收集 10 秒的資料。
即時收集堆積使用量和執行緒剖析資料。
在代理程式通知 Profiler 後端，表示已準備好擷取資料後，代理程式就會處於閒置狀態，直到後端回覆要擷取的剖析類型為止。如果同一個部署項目中，有 10 個應用程式執行個體正在運作，則要建立 10 個剖析代理程式。不過，這些代理程式大部分時間都會處於閒置狀態。在 10 分鐘的期間，您預期收會到 10 組剖析資料；針對每個剖析類型，每個代理程式平均會收到一個回覆。由於其中有些隨機作業，因此實際數量可能會有所不同。
Profiler 後端會使用 Profiler API 配額和剖析資料部署欄位來限制所擷取的剖析資料。如要瞭解如何查看和管理 Profiler 配額，請參閱「配額與限制」一文。
分析資料
Profiler 收集資料之後，您就可以使用 Profiler 介面查看和分析資料。
前往 Google Cloud 控制台的「Profiler」頁面：
您也可以透過搜尋列找到這個頁面。