診斷Java代碼中常見的數據庫性能熱點問題

　　當我在幫助一些開發者或架構師分析及優化Java應用程序的性能時，關鍵往往不在于對個別方法進行微調，以節省一或兩微秒的執行時間。雖然對某些軟件來說，微秒級的優化確實非常重要，但我認為這并非著眼點所在。我在2015年間對數百個應用進行了分析，發現多數性能與可伸縮性問題都來源于糟糕的架構決策、框架的錯誤配置、錯誤的數據庫訪問模式、過量的日志記錄，以及由于內存過度消耗而導致的垃圾回收所帶來的影響。

　　在我看來，性能工程的根本在于通過大量的觀察，將關鍵的架構指標、可伸縮性指標以及性能指標關聯在一起。通過對每次構建的結果以及不同負載情況下的表現進行分析，以發現系統中的回歸缺陷或瓶頸所在。以下圖中的儀表板作為示例：

　　(點擊放大圖像)

　　通過將系統負載、響應時間與SQL語句的執行次數等指標相關聯，可得出某些性能工程方面問題的根本原因。

　　最上面一張圖叫做“層分解”圖表，它顯示了你的應用中各個邏輯組件(例如Web Service、數據庫訪問、業務邏輯、Web服務器等等)的總體執行時間。紅色部分所表示的是某個后端Web Service所花費的時間，很明顯這里產生了一個組件熱點。我們同時可以發現，該Web Service并沒有承受異常的負載，因為從第二張圖來看，當時應用程序所處理的請求數量這條線比較平穩。一般情況下，整體響應時間多數都耗費在數據層，但這并不代表數據庫本身的速度緩慢!我了解，低效的數據庫訪問往往是造成性能不佳的主要原因，因此通常會結合分析SQL語句的執行次數。在這個示例中，已經能夠很清楚地看到它與大多數響應時間的峰值是相關的。

　　相關廠商內容

　　一路走來技術人的創業故事

　　未來物聯網中智能硬件的角色

　　人工智能的技術版圖

　　GMTC全球移動技術大會，8折優惠!

　　滴滴出行iOS客戶端架構演進之路

　　相關贊助商

　　ArchSummit深圳2016將于7月15-16在華僑城洲際大酒店舉行，現價8折搶購，團購報名更多優惠!

　　我所觀察到最常見的問題模式就是糟糕的數據庫訪問模式，此外還有過于細粒度的服務調用、糟糕的共享數據訪問共享、過度的日志記錄，以及由內存泄露以及大量的對象創建所導致的垃圾回收影響或是應用程序的崩潰。

　　可選的診斷工具

　　在本文中，我將專注于探討數據庫方面的問題，因為我十分確信你的所有應用都是因這些訪問模式中的某一種而產生問題的!你可以在市場上已有的各種性能診斷、追蹤，或是APM工具之間隨意選擇，不過我所選擇的是免費的Dynatrace Personal License。Java本身也提供了各種出色的工具，例如Java Mission Control等等。許多提供數據訪問功能的框架也經常通過其日志輸出提供各種診斷選項，例如Hibernate或Spring等等。

　　在使用這些跟蹤工具時，通常不需要對代碼進行任何修改，因為他們都利用了JVMTI(JVM Tooling Interface)以捕獲代碼層面的信息，甚至能夠跨遠程的各層次進行調用追蹤，這一點對于分布式、面向(微)服務的應用來說非常實用。你所要做的就是修改你的JVM啟動命令行選項，以加載這些工具。某些工具的開發商還提供了與IDE的集成功能，你只需簡單地表示“在運行時開啟XYZ性能診斷功能”。我在YouTube上做了一個簡單的視頻指南，演示了如何對在Eclipse中啟動的應用進行追蹤。

　　找出數據庫的性能熱點

　　即使你已經發現造成應用整體響應時間過長的主要原因在于數據庫，但也不要因此就輕率地指責數據庫與DBA!造成數據庫繁忙的原因可能有以下幾種：

　　對數據庫的使用過于低效：錯誤的查詢設計、糟糕的應用程序邏輯、對于數據訪問框架的配置不正確

　　糟糕的數據庫設計與數據結構：表的關聯、緩慢的存儲視圖、缺失的或錯誤的索引、過期的表統計信息

　　不恰當的數據庫配置，例如內存、磁盤、表空間、連接池等等

　　在本文中，我將著重講解如何在應用程序端將訪問數據庫所消耗的時間減至最低：

原文轉自：http://www.infoq.com/cn/articles/Diagnosing-Common-Java-Database-Performance-Hotspots