跳到主要內容

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


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



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


前言


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

留言

張貼留言

這個網誌中的熱門文章

架構設計 | 異步處理流程，多種實現模式詳解

本文源碼：GitHub·點這裏 || GitEE·點這裏 一、異步處理 1、異步概念 異步處理不用阻塞當前線程來等待處理完成，而是允許後續操作，直至其它線程將處理完成，並回調通知此線程。 必須強調一個基礎邏輯，異步是一種設計理念，異步操作不等於多線程，MQ中間件，或者消息廣播，這些是可以實現異步處理的方式。 同步處理和異步處理相對，需要實時處理並響應，一旦超過時間會結束會話，在該過程中調用方一直在等待響應方處理完成並返回。同步類似電話溝通，需要實時對話，異步則類似短信交流，發送消息之後無需保持等待狀態。 2、異步處理優點 雖然異步處理不能實時響應，但是處理複雜業務場景，多數情況都會使用異步處理。 異步可以解耦業務間的流程關聯，降低耦合度； 降低接口響應時間，例如用戶註冊，異步生成相關信息表； 異步可以提高系統性能，提升吞吐量； 流量削峰即把請求先承接下來，然後在異步處理； 異步用在不同服務間，可以隔離服務，避免雪崩； 異步處理的實現方式有很多種，常見多線程，消息中間件，發布訂閱的廣播模式，其根據邏輯在於先把請求承接下來，放入容器中，在從容器中把請求取出，統一調度處理。 注意 ：一定要監控任務是否產生積壓過度情況，任務如果積壓到雪崩之勢的地步，你會感覺每一片雪花都想勇闖天涯。 3、異步處理模式 異步流程處理的實現有好多方式，但是實際開發中常用的就那麼幾種，例如： 基於接口異步響應，常用在第三方對接流程； 基於消息生產和消費模式，解耦複雜流程； 基於發布和訂閱的廣播模式，常見系統通知 異步適用的業務場景，對數據強一致性的要求不高，異步處理的數據更多時候追求的是最終一致性。 二、接口響應異步 1、流程描述 基於接口異步響應的方式，有一個本地業務服務，第三方接口服務，流程如下： 本地服務發起請求，調用第三方服務接口； 請求包含業務參數，和成功或失敗的回調地址； 第三方服務實時響應流水號，作為該調用的標識； 之後第三方服務處理請求，得到最終處理結果； 如果處理成功，回調本地服務的成功通知接口； 如果處理失敗，回調本地服務的失敗通知接口； 整個流程基於部分異步和部分實時的模式，完整處理； 注意 ：如...
張貼留言
閱讀完整內容

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue) 目錄 引言 時間真快，轉眼今年又要過去了。回想今年，依次開源發布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ，這些框架及組件都是本着以實際出發，實事求是的態度，力求提高開發效率（我自己都是第一個使用者），目前來看反響不錯。但是隨着前端和後端技術的不斷變革，尤其是前端，目前大環境已經是前後端完全分離為主的開發模式，在這樣的大環境和必然趨勢之下，傳統的MVC就顯得有些落伍了。在這樣的背景下，一款前後端分離的.NET開發框架就顯得尤為必要，由此便定了框架的升級目標： 前後端分離 。 首先後端技術的選擇，從目前的數據來看，.NET Core的發展遠遠快於.NET Framework，最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚，但是星星卻後來居上而且比前者多30%，並且這個差距在不斷擴大，由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度，並不是某些人所認為的那麼不堪（ 走自己的路，讓別人說去吧 ）。大環境上微軟积極擁抱開源，大力發展.NET Core， 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ，不再浪費精力去支持.NET Framework。 然後是前端技術選擇，首選是三大js框架選擇，也是從實際出發，Vue相對其它而言更加容易上手，並且功能也毫不遜色，深得各種大小公司喜歡，如果偏要說缺點的話，那就是對TS支持不行，但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後，然後就是UI框架的選擇了，這裏的選擇更多了，我選擇了Ant Design Vue，理由便是簡潔方便，十分符合我的設計理念。 技術選型完畢之後便...
張貼留言
閱讀完整內容

台北市住宅、社區建創儲能設備 最高可獲600萬元補助

為了推廣分散式發電，台北市環保局預計補助1億元供住宅社區設置創能、儲能設備，計有3種方案可供選擇。環保局說明，每案補助額度不超過建制總經費49％，社區每案最高可獲200萬至600萬元補助，住宅每案補助上限100萬元，5月1日起開放申請。 環保局說明，台北市溫室氣體排放量7成以上來自住商部門，其中以使用電力造成間接溫室氣體排放為大宗，台北市平均年用電量約159.86億度，1度電約等同排放0.5公斤二氧化碳，若想達成2050年淨零排放目標，僅靠節能減碳無法達成，必須發展綠色創能、儲能，並且參考歐洲、日本的做法，採分散式發電方式，推廣到社區、住家、商辦，達到供電自給自足目標。 因此，環保局推出「台北市住宅社區創能儲能及節能補助計畫」，補助對象為台北市轄內房屋所有權人及社區管理委員會，補助方案共計3種，每一申請人或每一場址僅能獲1次補助，每案補助額度不超過建置總經費49％為限，5月1日到7月31日開放申請，但補助經費用完即停止申請。 環保局說明，方案A補助對象以社區為主，公共區域申請創能儲能及節能項目，每案補助上限新台幣600萬元；方案B分為住宅或社區公共區域申請創能搭配儲能項目（創能或儲能方案不得單獨申請），社區每案補助上限新台幣400萬元，住宅每案補助上限100萬元。方案C補助對象也是社區，公共區域申請節能項目，每案補助上限新台幣200萬元。 網頁設計 最專業,超強功能平台可客製,窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機,請問 台中電動車 哪裡在賣比較便宜可以到台中景泰電動車門市去看看總店：臺中市潭子區潭秀里雅潭路一段102-1號。 電動車補助 推薦評價好的 iphone維修 中心擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、產品研發、系統規劃設置、專業團隊的太陽能發電廠商。 網頁設計 一頭霧水該從何著手呢? 回頭車 貨運收費標準宇安交通關係企業，自成立迄今，即秉持著「以誠待人」、「以實處事」的企業信念 台中搬家公司 教你幾個打包小技巧,輕鬆整理裝箱!還在煩惱搬家費用要多少哪？台中大展搬家線上試算搬家費用，從此不再擔心「物品怎麼計費」、「多...
張貼留言
閱讀完整內容