效能測試大概花了9、10個小時，快要趕上編碼所需的時間了.很多時間不是花在編碼上，而是尋找改進思路和查詢文件上.
這一版花的時間最長，大概佔了一半時間，是因為要對整個生成數獨進行重構，而後幾版只是區域性優化.
對首版的sudoku1.0進行效能測試：
問題發現在生成1000000個數獨的情況下，生成的時間效率不高，尤其是使用dfs填入數字的時候.在查閱相關資料，發現了重大的演算法實現問題.根據原來的演算法，在基礎一位陣列的首位數字固定的情況下.使用這種演算法，只能得到8！=40320個不重複的數獨終局遠小於1000000個.因此對createsudokun函式及其內部的dfs函式進行重寫.
解決方案
修改思路：在8！個數獨的基礎上進行行交換，在1個數獨的基礎上得到另外不同72個數獨.
這次的**是正確的滿足1000000個不重複數獨的要求,但是花費時間還是很長24.935，只減少了2+秒.
問題他的寫檔案fprint函式占用了86.96%的cup.
檢視網路上其他人的優化，發現是每一建立完新的數獨就往檔案裡寫入，會浪費很長的時間.
解決方案
於是決定將100萬個數獨矩陣先存入乙個string變數中，最後在一次性寫入檔案.每個數獨生成乙個string，不斷的合併入最終的寫入string.
發現這種方法有明顯的改善，時間減少了58%.
問題但是檢視發現在getarrystring中字串string合併每乙個數獨，浪費了72.79%的時間
解決方案
將100萬個矩陣存入乙個char陣列中，最後將這個char陣列寫入檔案.
時間降到了6.164秒
問題檢視發現在現在fprintf已經降到了26.38%，這是佔主要cpu的是perm函式中生成基礎數獨的dfs，
解決方案
考慮對每乙個基礎dfs數獨不止進行行交換，並且進行列交換的可行性.
時間已經將到了2.345秒.
問題檢視發現在現在perm函式降到了24.97%，反而fprint又佔最大比例71.49%，此時無法進一步對fprint降速.
問題發現用時26.444s，這是佔主要cpu的是solv函式解數獨函式，無法進行優化.
解決方案
重構**放棄dfs，可以考慮dlx，但是沒有時間做出修改.
修改一下輸出格式問題
HDFS效能測試及優化部署
hadoop的儲存系統hdfs在大資料領域有著無可比擬的地位，本篇文章對hdfs的儲存效能做乙個相對詳細的測試，影響因素有哪些，來幫助我們優化部署應用程式和hadoop集群，最大化利用hadoop的吞吐能力。hdfs是hadoop分布式計算中的資料儲存系統 在hdfs中，檔案的讀寫過程就是clien...
Essbase效能優化測試
essbase效能優化方案 通過修改essbase.cfg檔案來調整整個資料庫引數 serverthreads 600 netdelay 17500 calccache true calccachehigh 400000000 calccachedefault 64000000 calccachel...
效能測試之效能優化篇
系統上線必會經歷測試階段，功能測試我們可以按照產品的設計原型去執行一條條測試用例來覆蓋產品功能點。但是在功能測試之外，如果乙個使用者介面層服務，我們還需要知道服務的效能指標以了解並評估這個服務在實際的生產環境中可以應對多大壓力，我們可以根據這個資料情況根據不用的場景時間去對應的增加機器節點或進行重構...