背景

使用C++開發(fā)了一個Redis數(shù)據(jù)導(dǎo)入工具 
從oracle中將所有表數(shù)據(jù)導(dǎo)入到redis中； 
不是單純的數(shù)據(jù)導(dǎo)入，每條oracle中的原有記錄，需要經(jīng)過業(yè)務(wù)邏輯處理， 
并添加索引（redis集合）； 
工具完成后，性能是個瓶頸；

優(yōu)化效果

使用了2個樣本數(shù)據(jù)測試： 
樣本數(shù)據(jù)a表8763 條記錄； 
b表940279 條記錄；

優(yōu)化前，a表耗時11.417s； 
優(yōu)化后，a表耗時1.883s；

用到的工具

gprof, pstrace,time

使用time工具查看每次執(zhí)行的耗時，分別包含用戶時間和系統(tǒng)時間； 
使用pstrace打印實時運行，查詢進程主要的系統(tǒng)調(diào)用，發(fā)現(xiàn)耗時點； 
使用gprof統(tǒng)計程序的耗時匯總，集中精力優(yōu)化最耗時的地方； 

使用簡介： 

1.對g++的所有編輯和連接選項都必須要加上-pg（第一天由于沒有在連接處加上-pg選項，導(dǎo)致無法出統(tǒng)計報告）； 
2.執(zhí)行完程序后，本目錄會產(chǎn)生gmon.out文件； 
3.gprof redistool gmou.out > report,生成可讀文件report，打開report集中優(yōu)化最耗時的函數(shù)；

優(yōu)化過程

優(yōu)化前11.417s：

文件內(nèi)存映射

系統(tǒng)調(diào)用時間過長，主要是文件讀寫，初步考慮是讀取文件時，調(diào)用api次數(shù)過于頻繁； 
讀取樣本采用的是文件fgets一行行的讀取，采用文件內(nèi)存映射mmap后，可直接使用指針操作整個文件內(nèi)存快；

日志開關(guān)提前

改進了文件讀寫后，發(fā)現(xiàn)優(yōu)化效果比較有限（提高了2s左右）；fgets是C的文件讀取庫函數(shù)，相比系統(tǒng)read()，是帶了緩沖區(qū)了，應(yīng)該不會太慢（網(wǎng)上有人測試，文件內(nèi)存映射相比fgets()能快上一個數(shù)量級，感覺場景應(yīng)該比較特殊）；

之后通過pstrace工具發(fā)現(xiàn)log.dat打開次數(shù)過多；原來是調(diào)試日志的開關(guān)寫到了后面，導(dǎo)致 調(diào)試日志都是會打開日志文件open("log.dat")； 
將日志開關(guān)提前；改進后，3.53s

vector空間預(yù)先分配

后續(xù)通過gprof分析，某個函數(shù)的vector內(nèi)存分配次數(shù)多，并有不少復(fù)制次數(shù)： 
改進以下這行代碼：

vector <string> vSegment;
使用靜態(tài)vector變量，并預(yù)先分配內(nèi)存：

優(yōu)化后，提升至2.286s

同樣，另外一個類中的成員vector也使用預(yù)先分配空間（在構(gòu)造函數(shù)中)：

m_vtPipecmd.reserve(256);
優(yōu)化后，提升至2.166s;

函數(shù)改寫 && 內(nèi)聯(lián)

繼續(xù)執(zhí)行程序，發(fā)現(xiàn)SqToolStrSplitByCh()函數(shù)消耗過大，改寫整個函數(shù)邏輯，并將改寫后的函數(shù)內(nèi)聯(lián)： 
優(yōu)化后，提升至1.937s

去除調(diào)試符和優(yōu)化監(jiān)測符號

最后，去掉debug和pg調(diào)試符號后，最終效果為1.883s；

滿足生產(chǎn)要求

以上最后幾步看似毫秒級的提升，擴大到全表數(shù)據(jù)后，效果就很明顯了； 
優(yōu)化后，生產(chǎn)上a表為152w，導(dǎo)入耗時大約326s（~6分鐘）； 
b表數(shù)據(jù)420w，導(dǎo)入耗時大約1103s（~18分鐘）

以上所述就是本文的全部內(nèi)容了，希望大家能夠喜歡。