亚洲好骚综合-亚洲黄色录像-亚洲黄色网址-亚洲黄色网址大全-99久久99久久-99久久99久久精品国产

您的位置:軟件測試 > 開源軟件測試 > 開源單元測試工具 >
客戶機應用程序的性能測試
作者:網絡轉載 發布時間:[ 2013/2/21 14:52:40 ] 推薦標簽:

關于線程后值得一提的是:除非您的確需要,不要頻繁休眠。 清單 8 說明了一個不當行為的例子:

清單 8. 頻繁休眠

               
while(someCondition) {
    ...more code here...
    Thread.sleep(aFewMilliseconds);
    ...more code here...
}


這么做的應用程序都會在該代碼塊處創建大量不必要的垃圾 并生成大量上下文切換。您不應當使用頻繁休眠, 而應使用 java.util.concurrent 提供的更高級別同步類,如 BlockingQueue、Semaphore、FutureTask 或者 CountDownLatch。 這些同步類提供了一種在等待條件變為真時不消耗 CPU 的途徑。 當您調用第三方代碼而這些代碼沒有使用監視器的有些時候不可能達到上面的要求, 在此情況下,您所能采取的佳做法 是嘗試在進行池操作時使創建的垃圾量小。

分析并提高啟動性能

對于 RCP 應用程序而言,提高其啟動性能是一項挑戰。 一般而言,啟動性能是由磁盤 I/O、類載入和字節碼驗證綜合而成的功能。 當然,如果在您的包內加入過多工作,也可能使其啟動緩慢,但是通常情況下 這并不是啟動中耗時的一部分。 啟動往往會由于許多個小的時間消耗而變得及其緩慢。 通常不會有任何一件事情消耗大量時間,而是每件事都只消耗少量時間, 但當其累積起來后終導致了大量時間的消耗。

RCP 應用程序構建于 OSGi 之上,它是面向 Java 的動態模塊系統(Dynamic Module System)。OSGi 提供了一種簡單的手段以全局方式鉤取類的裝載。 有人已經利用這種類裝載鉤子來創建 Java 類緩存,從而避免頻繁訪問磁盤并提高 啟動速度。這種技術很有前途,不過尚需更多研究以確定其功效。

為了提高啟動速度,Eclipse 鼓勵的另一項技術是 包按需激活(lazy bundle activation):直到某個包需要時才被裝載并激活。 一般在分析啟動性能時,我會收集所有激活包的列表以及對應于它們為何激活的堆棧跟蹤信息。 接著通覽列表,判斷我是否認為該包確實應該在啟動時被激活。 如果我認為有個包在啟動時不需要,我會刪除它以提高啟動性能(同時看發生了什么中斷)。 一旦我知道了刪除包后導致何種提高效果, 我聯系該代碼的開發人員,與之討論刪除或延遲對該包的激活。

要想收集包激活和類裝載信息,可使用如 清單 9 所示的調試選項,也可在 org.eclipse.osgi 包的 .options 文件中找到, 或者看看 CVS 的近版本(請參閱 參考資料):

清單 9. 啟用 OSGi 調試選項

               
org.eclipse.osgi/debug=true
org.eclipse.osgi/debug/bundleTime=true
org.eclipse.osgi/debug/monitorbundles=true
org.eclipse.osgi/monitor/activation=true
org.eclipse.osgi/monitor/classes=true


不過,插件開發人員可能自行其是阻撓按需裝載。 有個例子,我曾參與一個產品,它有一套堆棧視圖。對它定義了一個擴展, 以便于其他人能夠貢獻自己的堆棧視圖。在啟動的時候,可能只有一個或者沒有視圖可見, 但該擴展的作者提前創建了這些視圖, 即使它們根本不會展現出來。后來把改擴展改為只顯示視圖的標題和圖標, 直到終端用戶真的嘗試看該視圖時,才激活加入到擴展中的那個包。

另外一個例子,假設您正在創建一個應用程序,它有一個登錄對話框。 您的目的是僅激活用于顯示登錄對話框的包。 我曾經看到有些應用程序,為了顯示登錄對話框激活了所有包的 70%。

作為一種手段,我建議您開發一個 shell 游戲,它的啟動時間可以有所浮動但是總和保持相同。 用戶不必為他尚未使用到的特性付出等待時間。 這樣做的目的是只為需要付出而不是為所有東西付出時間。 如果某個應用程序在您做了所有提高性能的努力后仍然不夠快, 那么不要忘記提高用戶在感覺上的性能。

結束語

我特別強調在您的應用程序架構和設計階段考慮性能。 起碼,架構師或者首席開發人員必須知道基本的順序分析或時間復雜性(比如 Big O), 以便理解應用程序的存儲需求或執行時間隨應用程序增長如何改變。 后才考慮解決性能問題是被動的 —— 也很低效 —— 因為在游戲后期幾乎已不可能再去對架構做大的調整。

不過即使是擁有好的架構的應用程序也會有性能瓶頸, 您需要使用工具和技術了解并處理瓶頸。 現在您了解了如何度量 RCP 應用程序性能,判定是 CPU 還是 I/O 瓶頸導致了速度降低, 使用一些記錄技術,保持 UI 線程可響應,用 Job 回避線程誤用, 以及提高啟動性能。

理解一個富客戶機(Rich Client Platform(RCP))平臺應用程序的完整內存使用 會是一項腦力勞動。操作系統(OS)會指出應用程序耗費了多少內存,Java™ 平臺會指出 您已經耗費了多少堆。操作系統匯報的內存使用情況總是高于可用堆大小。 不幸的是,有時操作系統所報告的數目會遠遠 大于堆大小。 對于堆分析的一個挑戰是判斷這片 “黑暗空間” 中藏匿著什么。

一般而言:進程使用的內存 = Java 堆 + 已編譯的本地代碼 + 字節碼 + 其他 / 本地

很不幸,JVMS 根據其發行版本和供應商的不同,指示出的堆大小也不同。 我所運行的一個 Java 應用程序可以給出一些例子:Sun 1.6 JDK 報告堆大小為 32.7MB , 而操作系統報告為 48.6MB 私有字節,有 16MB 未作說明。總的來說這還算不錯。 已編譯代碼和字節碼是這 16MB 的一部分。 用 IBM® 1.5 JDK 運行同一應用程序,堆加上類加載器和已編譯代碼總共 是 39MB,而 OS 報告的大小為 45.8MB。

一般而言,您可以把問題簡化為只關注 Java 堆。 這對絕大多數 Java 應用程序而言已經足夠了,而且也可以讓應用程序做到大程度的改進。 如果還不夠,那么您應該使用操作系統工具檢查未被 Java 堆覆蓋的本地內存。

差異分析(Differential analysis)

處理內存使用問題中為行之有效的一種手段是關注對象數目。 舉例而言,如果要在某個郵件應用程序中顯示 50 條郵件消息, 那么需要多少個 MailMessage 類的實例? 50,對嗎?那么郵件詳情或其他郵件域對象呢?如果切換了文件夾,顯示新的 50 條郵件消息,又將發生什么情況呢? 您會擁有多少個對象:50 還是 100?

一旦開始進行此類分析,您會對 實例數目大大超過期望數目這一常見情形感到驚訝。注意:在您收集堆轉儲之前,確保 已經發生了垃圾收集行為,因為您不會想去考慮那些已經死亡的對象。 一般情況下,我會在捕獲堆轉儲前做一個 System.gc() 操作。

我并不想去描述司空見慣的一般性堆分析(請參閱 參考資料)。 相反,我將介紹差異分析(differential analysis),這是用于發現應用程序中內存泄漏的技術。

它的基本思想很簡單:

    得到一個堆轉儲。
    在應用程序中多次做某件事(假設做 10 次)。
    得到另一個堆轉儲。
    比較兩個堆轉儲中應用程序對象的數目。

這樣可以構建所需應用程序對象集合。 隨著泄漏的發現和處理,將泄漏到腳本的類添加到一個列表。 這樣一來,不長時間可以構建經常檢查的應用程序對象集合。

單元測試

我所用的另一個技術是寫單元測試,解析堆轉儲并對期望的域對象實例數目做斷言。 比如說,您可以啟動應用程序,運行一個場景,得到一個對轉儲,接著做斷言。 下面是一個例子:在郵件應用程序中發現一個內存泄漏,當該泄漏被處理后,我希望確定 在以后的代碼改變中不會再發生該問題,于是為此構建了一個單元測試。這是一個資源使用 單元測試,如清單 1 所示:

清單 1. JUnit 測試用例,解析堆轉儲

               
public void testOpenTenMessages() throws Exception {
Heap heap = Heap.from("openMessages.phd");
assertEquals(10, heap.instancesOf("cbg/mail/ui/message/MessageController"));
assertEquals(10, heap.instancesOf("cbg/mail/ui/message/viewer/AttachmentModel"));

Heap heapAfter = Heap.from("openMessagesClosed.phd");
assertEquals(0, heapAfter.instancesOf("cbg/mail/ui/message/MessageController"));
assertEquals(0, heapAfter.instancesOf("cbg/mail/ui/message/viewer/AttachmentModel"));
}


其工作原理是:打開 10 條郵件消息,創建名為 openMessages.phd 的堆轉儲。 然后關閉消息并創建第二個堆轉儲,命名為 openMessagesClosed.phd。

針對這兩個堆轉儲文件,現在對內存中所需域對象數目做斷言。 我期望在第一個轉儲中有 10 條郵件消息(MessageControllers), 在第二個中沒有任何郵件消息。

這種自動堆分析是對不同構建之間的變化做跟蹤的有力途徑。 和標準單元測試一樣,您可以僅在發現和處理內存泄漏時才創建此類單元測試。 把應用程序中的資源使用看作應被跟蹤的另一個量度信息是有益的。 即便是知道應用程序在運行后分配了多少個對象,也有助于構建的發展。

不幸的是,不同的 JVM(即便是相同 JVM 的不同版本)在堆分析上有著極大的不同。 IBM JVM 改變過幾次堆分析格式。Sun 的 JVM 使用另一種格式,并且在每次發布時也做過改動。

 


 回頁首


圖形設備接口資源的泄漏

在 Windows® 操作系統中,每個顏色、字體、圖形上下文(graphics context(GC))、圖像、光標或者區域都對應于一個單獨的圖形設備接口(graphical device interface(GDI))資源。 GDI 是 Windows 的術語,不過每個 OS 都有一個對應物。重要的是整個 OS 所擁有的 GDI 資源數目是有限的。 如果應用程序泄漏或使用了過多的資源,將會影響到系統上所運行的所有應用程序。GDI 泄漏很糟糕。

判斷 GDI 資源是否泄漏比較簡單。在 Windows OS 中,您可以使用 Task Manager 或 Process Explorer。 添加 GDI 列,觀察它是否隨時間而增長(參看圖 1)。比如說,您可能注意到每當打開一條郵件消息, 與 javaw 進程關聯的 GDI 資源數目會增加 50,但是當您關閉郵件消息后, GDI 資源的數目只減少 46。您每閱讀一條郵件消息,會泄漏 4 個 GDI 資源。

盡管 Task Manager 能告訴您何時 發生了泄漏, 但它不能幫您發現哪里 發生著泄漏。要做到這點,好的辦法是使用 Sleak,一個 SWT 開發工具(請參閱 參考資料)。 您可以啟用 SWT 所擁有的調試標記,使它跟蹤 GDI 資源的創建位置。 Sleak 讓您看到 GDI 資源以及它們是從哪里分配的。

上一頁12345下一頁
軟件測試工具 | 聯系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網站地圖
滬ICP備07036474 2003-2017 版權所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd
主站蜘蛛池模板: 亚洲一区二区三区精品影院 | 国产网站免费 | 欧美性视频18~19 | 一区二区三区高清在线观看 | 一个人看的www视频免费观看 | 在线看的黄色网址 | 国产精品国产三级国产an不卡 | 女攻高h全肉污文play | 毛片大全免费看 | 日韩在线高清视频 | 综合丁香 | 成人免费黄色 | 欧美a在线观看 | 日韩欧美一区二区在线 | 国产成人理在线观看视频 | 视频在线a| 欧美一欧美一区二三区性 | 一级黄色片免费播放 | 亚洲欧美日韩中文字幕网址 | 人人澡天天澡夜夜澡 | 18年大片免费在线 | 在线播放交视频 | 老湿影院在线免费观看 | 久久厕所精品国产精品亚洲 | 在线亚洲成人 | 五月天亚洲视频 | 中文字幕在线观看一区 | video欧美 | 日本全黄录像视频 | 天天综合天天看夜夜添狠狠玩 | 涩涩网址| 久久99精品久久久久久园产越南 | 一本大道在线观看 | 一级片视频免费观看 | 国产成人国产在线观看入口 | 免费福利午夜影视网 | 天天射视频 | 日韩欧美一区二区三区免费看 | 日韩欧美福利 | 欧美日韩 在线播放 | 国产午夜视频 |