跳到主要內容

記一次接口性能優化實踐總結:優化接口性能的八個建議_台中搬家公司


※推薦台中搬家公司優質服務,可到府估價



台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家


前言


最近對外接口偶現504超時問題,原因是代碼執行時間過長,超過nginx配置的15秒,然後真槍實彈搞了一次接口性能優化。在這裏結合優化過程,總結了接口優化的八個要點,希望對大家有幫助呀~



  • 數據量比較大,批量操作數據入庫

  • 耗時操作考慮異步處理

  • 恰當使用緩存

  • 優化程序邏輯、代碼

  • SQL優化

  • 壓縮傳輸內容

  • 考慮使用文件/MQ等其他方式暫存,異步再落地DB

  • 跟產品討論需求最恰當,最舒服的實現方式


嘻嘻,先看一下我們對外轉賬接口的大概流程吧


1.數據量比較大,批量操作數據入庫


優化前:


//for循環單筆入庫
for(TransDetail detail:list){
insert(detail);
}

優化后:


// 批量入庫,mybatis demo實現
<insert id="insertBatch" parameterType="java.util.List">
insert into trans_detail( id,amount,payer,payee) values
<foreach collection="list" item="item" index="index" separator=",">(
#{item.id}, #{item.amount},
#{item.payer},#{item.payee}
)
</foreach>
</insert>

性能對比:






















單位(ms) for循環單筆入庫 批量入庫
500條 1432 1153
1000條 1876 1425

解析



  • 批量插入性能更好,更加省時間,為什麼呢?


打個比喻:假如你需要搬一萬塊磚到樓頂,你有一個電梯,電梯一次可以放適量的磚(最多放500),
你可以選擇一次運送一塊磚,也可以一次運送500,你覺得哪種方式更方便,時間消耗更少?

2.耗時操作考慮異步處理


耗時操作,考慮用異步處理,這樣可以降低接口耗時。本次轉賬接口優化,匹配聯行號的操作耗時有點長,所以優化過程把它移到異步處理啦,如下:


優化前:



優化后


匹配聯行號的操作異步處理



性能對比:


假設一個聯行號匹配6ms






















同步 異步
500條 3000ms ~
1000條 6000ms ~

解析:



  • 因為聯行號匹配比較耗時,放在異步處理的話,同步聯機返回可以省掉這部分時間,大大提升接口性能,並且不會影響到轉賬主流程功能。

  • 除了這個例子,平時我們類似功能,如用戶註冊成功后,短信郵件通知,也是可以異步處理的,這個優化建議香餑餑的~

  • 所以,太耗時的操作,在不影響主流程功能的情況下,可以考慮開子線程異步處理的啦。


3.恰當使用緩存


在適當的業務場景,恰當地使用緩存,是可以大大提高接口性能的。這裏的緩存包括:Redis,JVM本地緩存,memcached,或者Map等。


這次轉賬接口,使用到緩存啦,舉個簡單例子吧~


優化前


以下是輸入用戶賬號,匹配聯行號的流程圖



優化后:


恰當使用緩存,代替查詢DB表,流程圖如下:



解析:



  • 把熱點數據放到緩存,不用每次查詢都去DB拉取,節省了這部分查SQL的耗時,美滋滋呀~

  • 當然,不是什麼數據都適合放到緩存的哦,訪問比較頻繁的熱點數據才考慮緩存起來呢~


4. 優化程序邏輯、代碼


優化程序邏輯、程序代碼,是可以節省耗時的。


我這裏就本次的轉賬接口優化,舉個例子吧~


台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!



還在煩惱搬家費用要多少哪?台中大展搬家線上試算搬家費用,從此不再擔心「物品怎麼計費」、「多少車才能裝完」



優化前:


優化前,聯行號查詢了兩次(檢驗參數一次,插入DB前查詢一次),如下偽代碼:



punlic void process(Req req){
//檢驗參數,包括聯行號(前端傳來的payeeBankNo可以為空,但是如果後端沒匹配到,會拋異常)
checkTransParams(Req req);
//Save DB
saveTransDetail(req);
}

void checkTransParams(Req req){
//check Amount,and so on.
checkAmount(req.getamount);
//check payeebankNo
if(Utils.isEmpty(req.getPayeeBankNo())){
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
if(Utils.isEmpty(payeebankNo){
throws Exception();
}
}
}

int saveTransDetail(req){
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
req.setPayeeBankNo(payeebankNo);
insert(req);
...
}


優化后:


優化后,只在校驗參數的時候插敘一次,然後設置到對象裏面~ 入庫前就不用再查啦,偽代碼如下:


void checkTransParams(Req req){
//check Amount,and so on.
checkAmount(req.getamount);
//check payeebankNo
if(Utils.isEmpty(req.getPayeeBankNo())){
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
if(Utils.isEmpty(payeebankNo){
throws Exception();
}
}
//查詢到有聯行號,直接設置進去啦,這樣等下入庫不用再插入多一次
req.setPayeeBankNo(payeebankNo);
}

int saveTransDetail(req){
insert(req);
...
}

解析:



  • 對於優化程序邏輯、代碼,是可以降低接口耗時的。以上demo只是一個很簡單的例子,就是優化前payeeBankNo查詢了兩次,但是其實只查一次就可以了。很多時候,我們都知道這個點,但就是到寫代碼的時候,又忘記了呀~所以,寫代碼的時候,留點心吧,優化你的程序邏輯、代碼哦。

  • 除了以上demo這點,還有其它的點,如優化if複雜的邏輯條件,考慮是否可以調整順序,或者for循環,是否重複實例化對象等等,這些適當優化,都是可以讓你的代碼跑得更快的。


之前我這篇文章,也提了幾個優化點噢,有興趣的朋友可以看一下哈~


寫代碼有這些想法,同事才不會認為你是複製粘貼程序員


5. 優化你的SQL


很多時候,你的接口性能瓶頸就在SQL這裏,慢查詢需要我們重點關注的點呢。


我們可以通過這些方式優化我們的SQL:



  • 加索引

  • 避免返回不必要的數據

  • 優化sql結構

  • 分庫分表

  • 讀寫分離


有興趣的朋友可以看一下我這篇文章呢,很詳細的SQL優化點:


後端程序員必備:書寫高質量SQL的30條建議


6.壓縮傳輸內容


壓縮傳輸內容,文件變得更小,因此傳輸會更快啦。10M帶寬,傳輸10k的報文,一般比傳輸1M的會快呀;打個比喻,一匹千里馬,它馱着一百斤的貨跑得快,還是馱着10斤的貨物跑得快呢?


解析:



  • 如果你的接口性能不好,然後傳輸報文比較大的話,這時候是可以考慮壓縮文件內容傳輸的,最後優化效果可能很不錯哦~


7. 考慮使用文件/MQ等其他方式暫存數據,異步再落地DB


如果數據太大,落地數據庫實在是慢的話,可以考慮先用文件的方式保存,或者考慮MQ,先落地,再異步保存到數據庫~



本次轉賬接口,如果是併發開啟,10個併發度,每個批次1000筆數據,數據庫插入會特別耗時,大概10秒左右,這個跟我們公司的數據庫同步機制有關,併發情況下,因為優先保證同步,所以并行的插入變成串行啦,就很耗時。



優化前:


優化前,1000筆先落地DB數據庫,再異步轉賬,如下:



優化后:


先保存數據到文件,再異步下載下來,插入數據庫,如下:



解析:



  • 如果你的耗時瓶頸就在數據庫插入操作這裏了,那就考慮文件保存或者MQ或者其他方式暫存吧,文件保存數據,對比一下耗時,有時候會有意想不到的效果哦。


8.跟產品討論需求最恰當,最舒服的實現方式


這點個人覺得還是很重要的,有些需求需要好好跟產品溝通的。



比如有個用戶連麥列表展示的需求,產品說要展示所有的連麥信息,如果一個用戶的連麥列表信息好大,你拉取所有連麥數據回來,接口性能就降下來啦。如果產品打樁分析,會發現,一般用戶看連麥列表,也就看前幾頁因此,奸笑,哈哈 其實,那個超大分頁加載問題也是類似的。即limit +一個超大的數,一般會很慢的~~



總結


本文呢,基於一次對外接口耗時優化的實踐,總結了優化接口性能的八個點,希望對大家日常開發有幫助哦~嘻嘻,有興趣可以逛逛我的github哈,本文會收藏到github里滴哈



https://github.com/whx123/JavaHome



公眾號




  • 歡迎關注我個人公眾號,交個朋友,一起學習哈~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益



擁有後台管理系統的網站,將擁有強大的資料管理與更新功能,幫助您隨時新增網站的內容並節省網站開發的成本。





Orignal From: 記一次接口性能優化實踐總結:優化接口性能的八個建議_台中搬家公司

留言

這個網誌中的熱門文章

有了四步解題法模板,再也不害怕動態規劃!(看不懂算我輸)

導言 動態規劃問題一直是算法面試當中的重點和難點,並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到,這篇文章的目的主要是解釋清楚 什麼是動態規劃 ,還有就是面對一道動態規劃問題,一般的 思考步驟 以及其中的注意事項等等,最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃,或者僅僅只有耳聞,或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 ",如果更準確些,其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中,大家經常會遇到一些系統配置的問題,配置不對,系統就會報錯,這個時候一般都會去 Google 或者是查閱相關的文檔,花了一定的時間將配置修改好。 過了一段時間,去到另一個系統,遇到類似的問題,這個時候已經記不清之前修改過的配置文件長什麼樣,這個時候有兩種方案,一種方案還是去 Google 或者查閱文檔,另一種方案是借鑒之前修改過的配置,第一種做法其實是萬金油,因為你遇到的任何問題其實都可以去 Google,去查閱相關文件找答案,但是這會花費一定的時間,相比之下,第二種方案肯定會更加地節約時間,但是這個方案是有條件的,條件如下: 之前的問題和當前的問題有着關聯性,換句話說,之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中,可以看到的是,上面這兩個條件均滿足,大可去到之前配置過的文件中,將配置拷貝過來,然後做些細微的調整即可解決當前問題,節約了大量的時間。 不知道你是否從這些描述中發現,對於一個動態規劃問題,我們只需要從兩個方面考慮,那就是 找出問題之間的聯繫 ,以及 記錄答案 ,這裏的難點其實是找出問題之間的聯繫,記錄答案只是順帶的事情,利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話,接    動態規劃 算法是通過拆分問題,定義問題狀態和狀態之間的關係,使得問題能夠以遞推(或者說分治)的方式去解決。它的幾個重要概念如下所述。    階段: 對於一個完整的問題過程,適當的切分為若干個相互聯繫的子問題,每次在求解一個子問題...

我的USB為什麼總是無法識別,到底是為甚麼呢?這真的讓我好困擾

其實判斷軟件硬件問題很簡單,在別的機器或換個系統試試就可以了.有些小的問題不妨先用專門軟件格式化下.還有提醒你WINDOWS下格式化時要選擇FAT,不要選FAT32。 倘若插入後,在右下角彈出電腦正在嘗試連接此USB設備的一些信息,有時會彈出對話框讓用戶選擇,有些用戶還沒看清就點了否,或者因為電腦一些初始的設置問題,禁止了USB的一些功能。解決辦法:右鍵點"我的電腦",選"屬性"--"硬件"--"驅動器簽名",在此選擇"忽略",點"確定"。然後重新插上usb,還是不連的話,再右鍵點"我的電腦"--"屬性"--"硬件"--"設備管理器",從中找到"通用串行總線控制器",右鍵,然後"掃描檢測硬件改動"。如果都不行那就是USB識別程序或U盤的問題從控制面板進入添加或刪除硬件將所有USB設備都刪除,重新安裝需要使用的USB設備驅動程序,重新啟動電腦 USB CONNECTOR   USB CONNECTOR  USB CONNECTOR Orignal From: 我的USB為什麼總是無法識別,到底是為甚麼呢?這真的讓我好困擾

為何 Amazon 併購 Oracle 的可能性很大 ?

  2019 年 9 月份 Trefis 團隊建議《Trefis 建議:谷歌可以斥資 90 億美元收購 Nutanix》,最近又建議亞馬遜收購 Oracle。此文是其和《福布斯》雜誌的 Great Speculations 合作撰寫。   根據 Trefis 分析,亞馬遜併購 Oracle 有望帶來巨大的價值。雖然這個想法聽起來很雄心勃勃,但是為了使自己處於雲技術食物鏈的頂端,Oracle 可能是亞馬遜有史以來最好的收購對象。我們詳細說明為什麼亞馬遜可能會收購 Oracle,還在交互式儀錶板中估計了潛在交易的價值。我們的估計基於 Oracle 的獨立價值以及它作為與亞馬遜合併后的實體中一部分而具有的價值。    為何我們認為亞馬遜會收購 Oracle?      兩家公司的概況: 亞馬遜可能是在 2000 年代中期第一家打造公共雲生態系統的供應商,但 Oracle 從事數據庫業務已有近 40 年的歷史。 AWS 的想法是可以將基礎設施出租給希望存儲和計算資源方面減少費用的客戶。根據 Trefis 的估計,AWS 的企業價值高達 4930 億美元,EV/EBITDA 是 27 倍(2020 年 EBITDA 為 180 億美元)。 Oracle 因第一代雲產品失敗而很晚進入雲市場,該公司隨後在開發方面投入大量資金,旨在向市場推出第二代雲。根據 Trefis 的估計,Oracle 的企業價值應為 2510 億美元,EV/EBITDA 是 12.7 倍(2020 年 EBITDA 為 200 億美元)。 AWS 的方法是創建產品,然後讓用戶採用它。Oracle 已經長期擁有這樣的用戶群,卻無法滿足 AWS 能夠滿足的要求。結果是,儘管 Oracle 運行着全球近 50% 的數據庫,但如今 AWS 在公共雲市場的份額超過 40%,而 Oracle 甚至沒有躋身前五名。   理由1:客戶將獲得第二代架構的安全性和 AWS 的客戶服務,因而導致差異化產品與競爭。 由於市場上面臨微軟 Azure(已成為微軟 B2B 和 B2C 產品的底層結構)、谷歌雲(迎來新的掌門人)和 IBM 雲產品(收購 Red Hat 之後)的競爭,AWS 的先行優勢如今可能在減弱。 對老牌雲領導企業構成不利的另一個因素是,原本可以遷移到...