用于收集應用性能數據的系統和方法技術方案

本發明專利技術提供了用于收集應用性能數據的系統和方法。系統（100）包括用于托管服務器側應用（120）的服務器（110）。在服務器上包括插樁模塊（130）。插樁模塊可以選擇性地對服務器側應用的函數（125）進行插樁，以獲得插樁函數操作數據。插樁模塊還可以維持每個應用線程的插樁函數調用棧（190）。在服務器上包括采樣模塊（140）。采樣模塊可以對服務器側應用的應用線程進行采樣，以獲得采樣函數操作數據。采樣模塊可以基于通過插樁而獲得的時間戳的壽命以及根據棧的空虛度而對哪些線程執行服務器請求的確定中的至少一個，對應用線程進行采樣。

【技術實現步驟摘要】
【國外來華專利技術】
技術介紹
關鍵業務應用中的性能問題通常難以在測試環境中再現。在至少一些情況下，這可能是由于這些應用是針對試生產(pre-production)環境中的性能而測試和調諧的并且是針對性能測試合格后的生產而發布的。當應用面臨真實負載和真實數據時，測試環境通常難以甚至不可能測試將在生產環境中執行應用的所有條件。通常，僅以不頻繁的間隔暴露生產中的性能問題，例如當遇到具體數據、具體用戶交互、具體數據庫狀態和/或具體定時的特定組合時。由此，檢測并識別導致性能問題或難題的條件可能是挑戰性的?，F今的服務器側應用的常見架構模型基于反應原理。具體地，服務器在通過明確定義的協議(HTTP、RMI、S0AP等)接收到外部事件(請求)時執行一些工作，并可以向請求方發送響應(結果)。在接收到單個事件時執行的工作的單位有時被稱作“服務器請求”。服務器性能的主要指示器是服務器請求等待時間，即，接收請求事件直到發送響應之間經過的時間。性能分析師可能有興趣確定哪些服務器請求的執行耗費較長時間。存在旨在解決該需要的多個可用工具。性能分析師還可能有興趣看到長期運行服務器請求的內部細節， 以便理解并查明延遲的根本原因。這可能提出嚴格的技術挑戰。在同服務器請求的執行有關的所收集的數據的量和質量與數據收集的性能開銷之間一般存在較強的權衡。以下事實使該權衡甚至更加深刻當服務器請求開始時，服務器請求等待時間不是已知的；并且， 大多數數據收集技術不能夠追溯地捕獲數據。因此，在先系統可以強制所有服務器請求的數據收集或者請求的隨機選擇的子集的數據收集，并冒著丟失導致問題的服務器請求的風險。附圖說明圖1是根據實施例的用于收集應用性能數據的系統的框圖2是根據實施例的由報告模塊形成和顯示的服務器請求調用樹的表示； 圖3是根據實施例的用于使用執行服務器請求的應用線程的信息收集應用性能數據的方法的流程圖；以及圖4是根據實施例的用于使用應用線程的時間戳收集應用性能數據的方法的流程圖。具體實施例方式現在將參照所示意的示例實施例，并且這里將使用特定的語言來描述這些示例實施例。然而將理解，并不意在由此限制本專利技術的范圍。本專利技術的附加特征和優勢將從結合附圖作出的以下具體實施方式中顯而易見，這些附圖一起作為示例而示意了各個技術實施例。生產環境中部署的多層服務器應用所遇到的故障解決性能問題可能對信息技術(IT)人員來說是挑戰性的任務。應用性能約束通常不允許使用剖析工具(profilingtools)，并且，性能問題無法始終在測試環境中再現。隨著應用復雜度的升高以及應用更頻繁地使用一個或多個第三方組件，查明服務器請求的長等待時間的根本原因對應用的開發者來說可能是困難的。克服這種困難的先前努力僅收獲了有限的成功。這里描述了一種用于收集應用性能數據以找到所部署的業務應用中的故障點的系統和方法，其克服了上述困難中的許多困難。對跟蹤、采樣和其他數據收集技術的使用可以在以下多個級別進行1)在數據收集級別，最小化采樣和跟蹤的重疊，并將開銷保持為較低；2)在數據處理級別，調解采樣和跟蹤技術操作的不同方式；以及3)在圖形用戶界面級別，給用戶提供統一體驗。兩種用于收集應用性能數據(即“剖析”)的技術是跟蹤和采樣。跟蹤有時被稱作基于事件的剖析，并基于插樁(instrumentation)。插樁可以是為了捕獲所選函數的起始和結束而對應用代碼的修改，并可以是自動的。插樁有時被擴展為捕獲函數自變量、所選數據點或與應用執行相關的其他工件(artifact)。跟蹤能夠產生與應用執行有關的非常豐富和精確的信息，但是跟蹤經受非常大的開銷。典型的基于跟蹤的剖析器在平均Java語言應用中對所有函數(方法)進行插樁時可以施加約2500-4000%的開銷。換言之，與沒有剖析的相同應用相比，經過剖析的應用消耗中央處理單元(CPU)的約25至40倍的處理能力。這種大的開銷可能使跟蹤剖析器實際上不可用在生產環境中。采樣是另一種剖析技術，并且基于對應用內的所有線程的棧跟蹤(stack trace) 的周期性檢查。采樣一般不產生應用內的函數的起始和結束事件，并且通常無法獲取任何自變量。采樣可以在一些時間點處捕獲調用者-被調用者(即，從調用者調用的函數)關系， 并且，函數等待時間可以是僅在使用采樣時才估計的。采樣的強度是其與跟蹤相比相對較低的“成本”(即，開銷)。典型的基于采樣的剖析器在以較高頻率(當前高至約每秒100次或更多)進行采樣時可以施加約100%的開銷(即，與沒有剖析的相同應用相比，經過剖析的應用消耗約兩倍的CPU)。函數等待時間的近似的準確度隨著所取的樣本數而增大。可以提高采樣頻率，以增加樣本數，但是，提高的采樣頻率也增大了開銷?？商鎿Q地，剖析器可以運行更長時間以增加樣本總數。這提供了針對平均或合計服務器請求的合理數據。然而，如果僅非常少的服務器請求表現出性能問題(通常是這種情況)，則這可能不提供足夠的數據以進行分析。因此，采樣通常用于估算出應用一般在哪里花費了其大部分時間，但可能不適于甚至識別單獨服務器請求。一種可以滿足嚴格性能限制并同時提供對應用專員來說有用的信息的技術是選擇性代碼插樁。在選擇性代碼插樁中，僅對應用內的少數函數進行插樁。該插樁提供了函數入口 /出口事件，函數入口 /出口事件被加時間戳并作為由應用執行的一個或多個服務器請求的調用樹而呈現給用戶。該調用樹是不完整的，但是，對要插樁的函數的合適選擇可以至少實現對經受性能問題的應用組件(一個或多個)或模塊(一個或多個)的識別。然而，選擇性插樁仍然具有缺陷。盡管應用專員可能能夠識別耗費較長時間完成的函數調用，但是如果不存在與被調用者有關的足夠信息，則可能不會發現性能問題的根本原因?？梢酝ㄟ^將新插樁插入應用中來獲得與被調用者有關的信息。然而，這通常不是容易的任務。首先，性能分析師必須將應用代碼理解得好到足以識別潛在被調用者，并必須確保所添加的插樁不會將性能開銷增加至不可容忍的水平。其次，許多運行時環境不具有在運行時期間將插樁代碼注入應用中的能力。這種插樁改變可能意味著應用將在插樁計劃的每次改變時重新啟動，并在生產執行期間帶來各種業務級影響。這里描述了。方法包括選擇性地對服務器上的服務器側應用進行插樁，以獲得包括應用線程的時間戳的插樁函數操作數據。對具有比預定時間段更久的時間戳的應用線程進行采樣，以獲得采樣函數操作數據。將插樁函數操作數據和采樣函數操作數據進行組合，以形成統一的應用性能報告。參照圖1，根據實施例，提供了用于收集應用性能數據的系統100。該系統可以包括被配置為托管(host)服務器側應用120的服務器110。應用可以包括任何數目的函數 125和任何數目的線程?？梢韵蚝蛷姆掌靼l送應用請求170和響應180。例如，使用客戶端160的用戶可能希望訪問web應用或與web應用對接?？蛻舳丝梢韵蚍掌靼l送針對信息的請求170。服務器可以向客戶端發送響應180。本領域技術人員可以認識到，在客戶端與服務器之間可以存在任何數目的設備(如路由器、交換機、其他服務器等)，以便于在客戶端與服務器之間傳輸數據。在服務器110上可以包括插樁模塊130。插樁模塊可以被配置為對服務器側應用 120的函數進行插樁?？梢酝ㄟ^對應用的插樁來獲得函數操作數據。可以對任何數目的函數本文檔來自技高網...

【技術保護點】

【技術特征摘要】
【國外來華專利技術】

【專利技術屬性】
技術研發人員：P芬代森，
申請(專利權)人：P芬代森，
類型：發明
國別省市：