前情提要

繼協助調教批次程式處理緩慢與OOM問題以及選用效能調教方式評估之後，批次程式調教也終於迎來的結果，但也有新的發現，楊藝最喜歡的就是在這過程當中，印證想法的正確性，以及遭遇問題的解決方式，從中學習到的經驗。

效能測試結果

比較原舊程式與新程式的效能測試結果，執行約350萬筆資料，所處理時間約8小時又5分28秒。

調教過後的新版本程式，執行約350萬筆資料，耗時約48分3秒。

在此完全都只對Java程式進行了優化，並未使用到Store Procedure進行資料庫資料處理，就可達成如此效能提升。實際上新版程式的執行環境的配置還低於舊版程式的執行環境配置許多，因此這樣的效能提升是相當驚人的。同時也代表了，舊版本程式的寫法十分不當，即便在較好的測試環境執行起來也會十分緩慢。好的程式寫法同時具備清晰的邏輯以及高效能的執行，這是楊藝一直以來所追求的目標。

後續發現

楊藝將模擬的350萬筆測試資料刪除之後，再次進行了測試，現在只剩下4千多筆資料運行，新程式的效能遠比舊程式的效能慢上許多。楊藝從Log發現分頁一次撈取4萬筆資料，在350萬筆所花秒數約7秒鐘，而在4千多筆資料的情況下，有時候分頁撈的資料只有少少幾筆，甚至在分頁區間撈取的資料為0筆時，所花時間依然為7秒。

這讓楊藝好奇原因是什麼，因此進行了SQL查詢的執行計畫分析，發現Cost值相當的高，這可能是導致效能下降的原因之一。可能是楊藝先前做了350萬筆測試一次對DB進行大量Insert動作，並未對表做統計分析，測試完刪除資料後，也未做統計分析，因此DB的執行計畫並未更新，導致在小資料量的情況下，查詢的效能反而變差。而在楊藝對資料表進行了統計分析之後，執行計畫的Cost值也隨之下降，再次測試同樣的查詢SQL，Cost值下降到了45，這樣的情況下，楊藝會再進行一次測試，看看在小資料量的情況下，效能是否會提升。

因此再次比較了新舊程式，在4千多筆資料的情況下，查詢速度變快很多，一次分頁查詢4萬筆資料已經降到1~2秒內完成，新程式的執行時間依然比舊程式多，但相差也就是幾秒鐘的差距。楊藝進行程式行為分析，新版程式使用了許多優化技術，包含了分頁、分片、非同步等技術，這些技術在小資料量的情況下，因為前置處理的時間，過程中撈取資料的次數都會比舊程式來得多，反而會造成效能下降。

針對這一點楊藝可以理解，畢竟處理少量資料的情況下用了這麼多機制，光做準備作業的時間，舊程式寫法再差也早已開始處理資料。新版程式車才發動，舊版程式已經走路到隔壁的便利店，大概就是這種感覺。不過因為測試的關係，如果沒有模擬資料，資料本來就少少的。線上系統運行至今，已經是幾百萬筆資料得處理，因此不會後少量資料的情況發生。

心得結論

在進行程式效能調教的時候，除了進行程式本身的調整與做法，針對環境限制有配套方案之外，還要針對資料庫進行調教才行，如SQL查詢語法的調教是否每個查詢條件都有使用到索引，這一點楊藝在開發過程都有做，在實際運行的時候得對資料表進行統計分析，確保運行環境與調教時的執行計畫相符，才能保證程式與調教結果一致。

以上就是本篇文章的全部內容了~ 工作要楊藝，生活要洋溢~