?文章來源地址http://www.zghlxwxcb.cn/news/detail-589846.html
一、哪些因素會成為系統(tǒng)的瓶頸
?
-
CPU：如果存在大量的計算，他們會長時間不間斷的占用CPU資源，導致其他資源無法爭奪到CPU而響應緩慢，從而帶來系統(tǒng)性能問題，例如頻繁的FullGC，以及多線程造成的上下文頻繁的切換，都會導致CPU繁忙，一般情況下CPU使用率<75%比較合適。
?
-
內存：Java內存一般是通過jvm內存進行分配的，主要是用jvm中堆內存來存儲Java創(chuàng)建的對象。內存的讀寫速度非常快，但是內存空間又是有限的，當內存空間被占滿，對象無法回收時，就會導致內存溢出或內存泄漏。
?
-
磁盤I/O：磁盤的存儲空間要比內存存儲空間大很多，但是磁盤的讀寫速度比內存慢，雖然現(xiàn)在引入SSD固態(tài)硬盤，但是還是無法跟內存速度相比。
?
-
網絡：帶寬的大小，會對傳輸數據有很大影響，當并發(fā)量增加時，網絡很容易就會成為瓶頸。
?
-
異常：Java程序，拋出異常，要對異常進行捕獲，這個過程要消耗性能，如果在高并發(fā)的情況下，持續(xù)進行異常處理，系統(tǒng)的性能會受影響。
?
-
數據庫：數據庫的操作一般涉及磁盤I/O的讀寫，大量的數據庫讀寫操作，會導致磁盤I/O性能瓶頸，進而導致數據庫操作延遲。
?
當在并發(fā)編程的時候，經常會用多線程操作同一個資源，這個時候為了保證數據的原子性，就要使用到鎖，鎖的使用會帶來上下文切換，從而帶來性能開銷，在JDK1.6之后新增了偏向鎖、自旋鎖、輕量級鎖、鎖粗化、鎖消除。
?
二、哪些指標做為衡量系統(tǒng)的性能
?
?
-
數據庫響應時間，即數據庫操作的時間
-
服務端響應時間，服務端包括Nginx分發(fā)的請求所消耗的時間及服務端程序執(zhí)行所消耗的時間。
-
網絡響應時間，網絡傳輸，網絡硬件需要對傳輸的請求進行解析所消耗的時間
-
客戶端響應時間，一般Web、App客戶端，消耗時間可以忽略不計，但是如果客戶端存在大量的邏輯處理，消耗的時間有能能就會變長。
?
?
-
磁盤吞吐量：IOPS（Input/Output Per Second）每秒的輸入輸出量，這種是單位時間內系統(tǒng)能處理的I/O請求數量，I/O請求通常為讀或寫數據操作請求，關注隨機讀寫性能，適用于隨機讀寫頻繁的應用，如小文件存儲，郵件服務器。數據吞吐量，這種是單位時間可以傳輸的數據量，對于大量順序讀寫頻繁的應用，傳輸大量連續(xù)數據，例如視頻編輯。
?
-
網絡吞吐量：指網絡傳輸時沒有丟幀的情況下，設備能夠接受的最大數據速率。網絡吞吐量不僅跟帶寬有關系，還跟CPU處理能力、網卡、防火墻、以及I/O等緊密聯(lián)系，吞吐量的大小由網卡的處理能力、內部程序算法以及帶寬大小決定。
?
?
-
CPU使用率，首先可以先了解CPU的基本信息，包括物理CPU的個數、單個CPU的核數，然后可以通過命令查看使用率，vmstat、mpstat、top
-
內存使用率，free -m、vmstat、top
-
磁盤I/O， iostat、 iotop
-
網絡I/O，netstat、ifconfig、tcpstat
?
三、性能測試注意的問題
?
我們在做性能測試的時候，系統(tǒng)的運行會越來越快，后面的訪問速度比我們第一次訪問的速度快了好幾倍，這是因為Java語言編譯的順序是，.java文件先編譯為.class文件，然后通過解釋器將.class的字節(jié)碼轉換成本地機器碼后，才能運行。
?
為了節(jié)約內存和執(zhí)行效率，代碼最初被執(zhí)行時，解釋器會率先解釋執(zhí)行這段代碼。隨著代碼被執(zhí)行的次數增多，虛擬機發(fā)現(xiàn)某個方法或代碼運行的特別頻繁，就被認定為熱點代碼（Hot Spot Code）。
?
為了提高熱點代碼的執(zhí)行效率，在運行時虛擬機將會通過即時編譯器（JIT）把這些代碼編譯成為本地平臺相關的機器碼，然后儲存在內存中，之后每次運行代碼時，直接從內存中獲取。這樣就會導致第一次系統(tǒng)運行慢，后面訪問的速度快幾倍。
?
在做性能測試的時候，每次測試處理的數據集都是一樣的，但是結果卻有差異，這是因為測試時，伴隨著很多不穩(wěn)定因素，比如機器其他進程的影響、網絡波動以及每個階段JVM垃圾回收的不同等。我們可以通過多次測試，將測試結果求平均，只要保證平均值在合理范圍之內，并且波動不是很大，這種情況，性能測試就算通過。
?
四、定位性能問題的時候，可以使用自下而上的策略分析排查
?
當我們進行壓測之后，我們會輸出一份性能測試報告，其中包括，RT、TPS、TP99，被壓服務器的CPU、內存、I/O，以及JVM的GC頻率。通過這些指標可以發(fā)現(xiàn)性能瓶頸，我們可以采用自下而上的方式進行分析。
?
1. 首先從操作系統(tǒng)層面，查看系統(tǒng)的CPU、內存、I/O、網絡的使用率是否異常，再通過命令查找異常日志，最后通過日志分析，找到導致瓶頸的問原因。
?
2. 還可以從Java應用的JVM層面，查看JVM的垃圾回收頻率以及內存分配情況是否存在異常，分析垃圾回收日志，找到導致瓶頸的原因。
?
3. 如果系統(tǒng)和JVM層面都沒有出現(xiàn)異常情況，然后可以從應用服務業(yè)務層查看是否存在性能瓶頸，例如，Java編程問題，讀寫數據庫瓶頸等。
?
五、優(yōu)化性能問題的時候，可以使用自上而下的策略進行優(yōu)化
?
整體的調優(yōu)順序，我們可以從業(yè)務調優(yōu)到編程調優(yōu)，最后再到系統(tǒng)調優(yōu)。
?
?
首先是優(yōu)化代碼，代碼問題往往會因為消耗系統(tǒng)資源而暴漏出來，例如代碼導致內存溢出，使JVM內存用完，而發(fā)生頻繁的FullGC，導致CPU偏高。
?
其次是優(yōu)化設計，主要是優(yōu)化業(yè)務層和中間件層代碼，例如可以采用代理模式，放在頻繁調用的創(chuàng)建對象的場景里，共享一個創(chuàng)建對象，減少創(chuàng)建對象的消耗。
?
再次是優(yōu)化算法，選擇合適的算法降低時間復雜度。
?
?
1）表結構與索引優(yōu)化
?
主要是對數據庫設計、表結構設計以及索引設置維度進行的優(yōu)化，設計表結構的時候，考慮數據庫的水平與垂直的拓展能力，提前規(guī)劃好將來數據量、讀寫量的增長，規(guī)劃好分庫分表方案。對字段選擇合適的數據類型，優(yōu)先選用較小的數據結構。
?
2）SQL語句優(yōu)化
?
主要是對SQL語句進行的優(yōu)化，使用explain來查看執(zhí)行計劃，來查看是否使用了索引，使用了哪些索引。也可以使用Profile命令分析語句執(zhí)行過程中各個分步的耗時。
?
3）MySQL參數優(yōu)化
?
主要是對MySQL服務的配置進行優(yōu)化，例如連接數的管理，對索引緩存、查詢緩存、排序緩存等各種緩存大小進行優(yōu)化
?
4）硬件及系統(tǒng)配置
?
對硬件設備和操作系統(tǒng)設置進行優(yōu)化，例如調整操作系統(tǒng)參數、禁用swap、增加內存、升級固態(tài)硬盤。
?
?
首先是操作系統(tǒng)調優(yōu)，Linux操作的內核參數設置可以進行調優(yōu)，已達到提供高性能的目的。
?
其次，JVM調優(yōu)，設置合理的JVM內存空間，以及垃圾回收算法來提高性能，例如，如果業(yè)務邏輯會創(chuàng)建大對象，我們就可以設置，將大的對象直接放到老年代中，這樣可以減少年輕代頻發(fā)發(fā)生YongGC，減少CPU的占用時間。
?
?
首先是時間換取空間，有的時候系統(tǒng)對查詢速度要求不高，對存儲空間要求較高，這個時候我們可以考慮用時間換取空間。
?
其次是空間換取時間，用存儲空間提升訪問速度，典型的就是MySQL的分庫分表策略，MySQL表單數據存儲千萬以上的時候，讀寫性能就會下降，這個時候我們可以將數據進行拆分，以達到查詢的時候，每個表的數據是少量的，以達到提升性能的目的。
?
?
系統(tǒng)調優(yōu)后，仍然還會存在性能問題，這個時候我們需要有兜底策略， 首先是限流，對系統(tǒng)的入口設置最大訪問限制，同時采取斷熔措施，返回沒有成功的請求。其次是橫向擴容，當訪問量超過某一個閾值時，系統(tǒng)可以自動橫向增加服務。文章來源：http://www.zghlxwxcb.cn/news/detail-589846.html
?
到了這里，關于性能測試監(jiān)控指標及分析調優(yōu)指南的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
