響應(yīng)時間和訪問量
- 訪問量高峰期過萬畔规，平時日訪問量過千
- 高峰期響應(yīng)時間 400~1000ms，平時400ms
- 2臺服務(wù)器
- 500+行代碼
代碼結(jié)構(gòu)問題
- 內(nèi)部耦合性強序愚，內(nèi)聚性差
- 可讀性差蚂子，注釋少
- 代碼質(zhì)量差，潛伏bug多，出問題難以排查
優(yōu)化目標
- 優(yōu)化響應(yīng)時間汰现，800ms較慢
- 重構(gòu)代碼氛谜，加上必要注釋，便于后期維護
性能優(yōu)化
添加機器
分析：目前mobile-web兩臺機器酝惧，分析某一天（平常時候6月2號）機器榴鼎，兩臺機器的CPU使用率，發(fā)現(xiàn)比較正常晚唇，沒有過載的情況巫财。五月底因為某一天訪問量過高，CPU使用率一度升到40~60%哩陕。
優(yōu)化方案：
通讀代碼平项，發(fā)現(xiàn)很多循環(huán)SQL的情況，即根據(jù)列表ID悍及，循環(huán)查詢數(shù)據(jù)庫闽瓢，可以將這些合并為一次IO，一次查詢盡可能多的數(shù)據(jù)（在網(wǎng)絡(luò)不是瓶頸的情況下）
不少方法內(nèi)部邏輯類似心赶，可以優(yōu)化為一個方法
不少大表沒有建相應(yīng)的索引扣讼，全表掃描緩慢，可以針對性的建索引
循環(huán)查詢優(yōu)化
循環(huán)查詢的代碼：
使用 sqlalchemy in_語句缨叫，用mysql in來一次性查詢椭符，減少IO次數(shù)荔燎。
完全沒有優(yōu)化的情況：
未優(yōu)化時候，getTrainingListWithStatus方法耗時1400+ms销钝，優(yōu)化后有咨，響應(yīng)時間減少到1300+ms，減少了100多ms蒸健。
合并相同邏輯優(yōu)化
獲取培訓(xùn)列表方法getTrainingList中座享，內(nèi)部有個代碼片段，循環(huán)調(diào)用了兩個內(nèi)部邏輯大致相同的方法纵装，多了一次IO征讲，優(yōu)化一下，可以減少一倍的耗時橡娄。
可以合并為一個IO诗箍，然后作為參數(shù)傳入這兩個方法。
優(yōu)化以后挽唉，get_train_list方法耗時從1000+ms降到500+ms滤祖，減少了一倍。
建索引優(yōu)化：
培訓(xùn)列表涉及的數(shù)據(jù)表有：
- transporter_training; //表數(shù)據(jù)總量508瓶籽，一個city_id 有15-50條數(shù)據(jù); 目前有一個 id 索引匠童；擬在上面建city_id索引
- transporter_training_course; //表數(shù)據(jù)總量19105，目前有id索引塑顺，teacher_id索引汤求；擬在上面建（training_id,is_del）索引
- transporter_training_signup; //表數(shù)據(jù)50多萬，目前只有一個id索引严拒；擬建（transporter_id,is_valid,training_type）索引
- training_online;//表數(shù)據(jù)90多萬扬绪，989802，目前只有一個id索引裤唠，為全表掃描挤牛；擬建 transporter_id 索引
分析：添加索引后，整個training_list 耗時從1200+ms減少到890+ms种蘸。 可見添加索引后性能大大提升墓赴。
我的優(yōu)化到此結(jié)束，謝謝航瞭！
