跳到主要內容

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


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



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


前言


最近對外接口偶現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: 記一次接口性能優化實踐總結：優化接口性能的八個建議_台中搬家公司

留言

張貼留言

這個網誌中的熱門文章

Python 併發總結，多線程，多進程，異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程，並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量，限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...
張貼留言
閱讀完整內容

高雄十大包子名店出爐

, 圖文：吳恩文 高雄包子大賽落幕了，我只能就我個人意見， 介紹一下前十名這些包子，但是不能代表其他四位評審的意見，雖然身為評審長，我通常不會第一個表示意見，以免影響其他評審， 我主要工作是負責發問。   這次參賽的素包子很少，而且都不夠細致，又偏油，我不愛， 但是第一名的甜芝麻包－熔岩黑金包，竟然是素食得名－ 漢來蔬食巨蛋店。   這包子賣相太好，竹炭粉的黑色外皮刷上金粉，一上桌，眾人驚呼， 搶拍照，內餡是芝麻餡，混一點花生醬增稠，加入白糖芝麻油， 熔岩爆漿的程度剛剛好，我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇， 當下有二位評審就想宅配回家。   尤其特別的是，黑芝麻餡室溫易化，師傅必須要輪班躲在冷藏室內， 穿著大外套才能包，一天包不了多少，我笑說，漢來美食，集團餐廳那麼多，實力雄厚，根本是「 奧運選手報名參加村裡運動會」嘛，其他都是小包子店啊， 但是沒辦法，顯然大家都覺得它好看又好吃， 目前限定漢來蔬食高雄巨蛋店，二顆88元，可以冷凍宅配， 但是要排一陣子，因為供不應求，聽說，四月份， 台北sogo店開始會賣。   第二名的包子，左營寬來順早餐店，顯然平易近人的多，一顆肉包， 十塊錢，是所有參賽者中最便宜的，當然，個頭也小， 它的包子皮明顯和其他不同，灰灰的老麵，薄但紮實有嚼勁， 肉餡新鮮帶汁，因為打了些水，味道極其簡單，就是蔥薑，塩， 香油，薑味尤其明顯，是老眷村的味道， 而特別的是老闆娘是台灣本省人， 當年完全是依據眷村老兵的口味一步一步調整而來，沒有加什麼糖、 五香粉，胡椒粉，油蔥酥。就是蔥薑豬肉和老麵香，能得名， 應該是它的平實無華，鮮美簡單，打動人心。   這是標準的心靈美食，可以撫慰人心，得名之前，寛來順已經天天排隊，現在，恐怕要排更久了， 建議大家六七點早點上門。   第三名，「專十一」很神奇，我記得比賽最後， 大家連吃了幾家不能引起共鳴的包子，有些累，到了專十一， 就坐著等包子，其他評審一吃，就催我趕快試，我一吃， 也醒了大半。   它的包子皮厚薄適中，但是高筋麵粉高些，老麵加一點點酵母， 我心中，它的皮屬一屬二，至於餡又多又好吃，蛋黃還是切丁拌入， 不是整顆放，吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一，...
張貼留言
閱讀完整內容

韋伯連續劇終於更新 期待第一季順利完結

　　地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope，縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新：五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA 　　嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩，這個韋伯望遠鏡異常重要的親密夥伴，要是無法正常運轉的話，韋伯的這一季天文界連續劇說不準就要一直拖更了。 　　詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡，還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年，韋伯童鞋必須非常"冷靜"，體溫升高的話，靈敏度會大大折損。這個時候，遮陽罩就要大顯身手啦。 　　遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點，運行軌道很高，遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源，其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度；50 開爾文)。 上圖中我們可以看出，韋伯望遠鏡的配置大致可分為兩部分：紅色較熱的一面溫度為 85 攝氏度，藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中，儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci. 　　遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度，足以煮熟雞蛋，而背陰處的部分溫度極低，足以凍結氧氣。 　　工程師們剛剛完成了五層遮陽罩的測試，按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩，測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨，難度高，但測試順利完成，遮陽罩展開時的狀態非常驚艷"。 　　遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料， 耐高溫絕...
張貼留言
閱讀完整內容