如何理解Python接口優(yōu)化

這篇文章主要講解了“如何理解Python接口優(yōu)化”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“如何理解Python接口優(yōu)化”吧！

企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對(duì)外擴(kuò)展宣傳的重要窗口，一個(gè)合格的網(wǎng)站不僅僅能為公司帶來(lái)巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺(tái)，成都創(chuàng)新互聯(lián)面向各種領(lǐng)域：廣告設(shè)計(jì)等成都網(wǎng)站設(shè)計(jì)、成都營(yíng)銷(xiāo)網(wǎng)站建設(shè)解決方案、網(wǎng)站設(shè)計(jì)等建站排名服務(wù)。

背景

我們負(fù)責(zé)的一個(gè)業(yè)務(wù)平臺(tái)，有次在發(fā)現(xiàn)設(shè)置頁(yè)面的加載特別特別地慢，簡(jiǎn)直就是令人發(fā)指

讓用戶(hù)等待 36s 肯定是不可能的，于是我們就要開(kāi)啟優(yōu)化之旅了。

投石問(wèn)路

既然是網(wǎng)站的響應(yīng)問(wèn)題，可以通過(guò) Chrome 這個(gè)強(qiáng)大的工具幫助我們快速找到優(yōu)化方向。

通過(guò) Chrome 的 Network 除了可以看到接口請(qǐng)求耗時(shí)之外，還能看到一個(gè)時(shí)間的分配情況，選擇一個(gè)配置沒(méi)有那么多的項(xiàng)目，簡(jiǎn)單請(qǐng)求看看：

雖然只是一個(gè)只有三條記錄的項(xiàng)目，加載項(xiàng)目設(shè)置都需要 17s，通過(guò) Timing, 可以看到總的請(qǐng)求共耗時(shí) 17.67s ，但有 17.57s 是在 Waiting(TTFB) 狀態(tài)。

TTFB 是 Time to First Byte 的縮寫(xiě)，指的是瀏覽器開(kāi)始收到服務(wù)器響應(yīng)數(shù)據(jù)的時(shí)間（后臺(tái)處理時(shí)間+重定向時(shí)間），是反映服務(wù)端響應(yīng)速度的重要指標(biāo)。

Profile 火焰圖 + 代碼調(diào)優(yōu)

那么大概可以知道優(yōu)化的大方向是在后端接口處理上面，后端代碼是 Python + Flask 實(shí)現(xiàn)的，先不盲猜，直接上 Profile：

第一波優(yōu)化：功能交互重新設(shè)計(jì)

說(shuō)實(shí)話看到這段代碼是絕望的：完全看不出什么？只是看到很多 gevent 和 Threading，因?yàn)樘鄥f(xié)程或者線程？

這時(shí)候一定要結(jié)合代碼來(lái)分析（為了簡(jiǎn)短篇幅，參數(shù)部分用 “...” 代替）：

?def get_max_cpus(project_code, gids):      """      """      ...      # 再定義一個(gè)獲取 cpu 的函數(shù)      def get_max_cpu(project_setting, gid, token, headers):          group_with_machines = utils.get_groups(...)          hostnames = get_info_from_machines_info(...)          res = fetchers.MonitorAPIFetcher.get(...)          vals = [              round(100 - val, 4)              for ts, val in res['series'][0]['data']              if not utils.is_nan(val)          ]          maxmax_val = max(vals) if vals else float('nan')          max_cpus[gid] = max_val           #  啟動(dòng)線程批量請(qǐng)求      for gid in gids:          t = Thread(target=get_max_cpu, args=(...))          threads.append(t)          t.start()             # 回收線程      for t in threads:          t.join()      return max_cpus

通過(guò)代碼可以看到，為了更加快速獲取 gids 所有的 cpu_max 數(shù)據(jù)，為每個(gè) gid 分配一個(gè)線程去請(qǐng)求，最終再返回最大值。

這里會(huì)出現(xiàn)兩個(gè)問(wèn)題：

1.  在一個(gè) web api 做線程的 創(chuàng)建 和 銷(xiāo)毀 是有很大成本的，因?yàn)榻涌跁?huì)頻繁被觸發(fā)，線程的操作也會(huì)頻繁發(fā)生，應(yīng)該盡可能使用線程池之類(lèi)的，降低系統(tǒng)花銷(xiāo)；

2.  該請(qǐng)求是加載某個(gè) gid (群組) 下面的機(jī)器過(guò)去 7 天的 CPU 最大值，可以簡(jiǎn)單拍腦袋想下，這個(gè)值不是實(shí)時(shí)值也不是一個(gè)均值，而是一個(gè)最大值，很多時(shí)候可能并沒(méi)有想象中那么大價(jià)值；

既然知道問(wèn)題，那就有針對(duì)性的方案：

1.  調(diào)整功能設(shè)計(jì)，不再默認(rèn)加載 CPU 最大值，換成用戶(hù)點(diǎn)擊加載（一來(lái)降低并發(fā)的可能，二來(lái)不會(huì)影響整體）；

2.  因?yàn)?1 的調(diào)整，去掉多線程實(shí)現(xiàn)；

再看第一波優(yōu)化后的火焰圖：

這次看的火焰圖雖然還有很大的優(yōu)化空間，但起碼看起來(lái)有點(diǎn)正常的樣子了。

第二波優(yōu)化：MySQL 操作優(yōu)化處理

我們?cè)購(gòu)捻?yè)面標(biāo)記處（接口邏輯處）放大火焰圖觀察：

看到好大一片操作都是由 utils.py:get_group_profile_settings 這個(gè)函數(shù)引起的數(shù)據(jù)庫(kù)操作熱點(diǎn)。

同理，也是需要通過(guò)代碼分析：

def get_group_profile_settings(project_code, gids):          # 獲取 Mysql ORM 操作對(duì)象      ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))      session = get_postman_session()          profile_settings = {}      for gid in gids:          compound_name = project_code + ':' + gid          result = session.query(ProfileSetting).filter(              ProfileSetting.name == compound_name          ).first()                if result:              resultresult = result.as_dict()              tag_indexes = result.get('tag_indexes')              profile_settings[gid] = {                  'tag_indexes': tag_indexes,                  'interval': result['interval'],                  'status': result['status'],                  'profile_machines': result['profile_machines'],                  'thread_settings': result['thread_settings']              }              ...(省略)      return profile_settings

看到 Mysql ，第一個(gè)反應(yīng)就是 索引問(wèn)題，所以?xún)?yōu)先去看看數(shù)據(jù)庫(kù)的索引情況，如果有索引的話應(yīng)該不會(huì)是瓶頸：

很奇怪這里明明已經(jīng)有了索引了，為什么速度還是這個(gè)鬼樣子呢！

正當(dāng)毫無(wú)頭緒的時(shí)候，突然想起在 第一波優(yōu)化 的時(shí)候， 發(fā)現(xiàn) gid（群組）越多的影響越明顯，然后看回上面的代碼，看到那句：

for gid in gids:       ...

我仿佛明白了什么。

這里是每個(gè) gid 都去查詢(xún)一次數(shù)據(jù)庫(kù)，而項(xiàng)目經(jīng)常有 20 ~ 50+ 個(gè)群組，那肯定直接爆炸了。

其實(shí) Mysql 是支持單字段多值的查詢(xún)，而且每條記錄并沒(méi)有太多的數(shù)據(jù)，我可以嘗試下用 Mysql 的 OR 語(yǔ)法，除了避免多次網(wǎng)絡(luò)請(qǐng)求，還能避開(kāi)那該死的 for

正當(dāng)我想事不宜遲直接搞起的時(shí)候，余光瞥見(jiàn)在剛才的代碼還有一個(gè)地方可以?xún)?yōu)化，那就是：

看到這里，熟悉的朋友大概會(huì)明白是怎么回事。

GetAttr 這個(gè)方法是Python 獲取對(duì)象的 方法/屬性 時(shí)候會(huì)用到，雖然不可不用，但是如果在使用太過(guò)頻繁也會(huì)有一定的性能損耗。

結(jié)合代碼一起來(lái)看：

def get_group_profile_settings(project_code, gids):        # 獲取 Mysql ORM 操作對(duì)象      ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))      session = get_postman_session()         profile_settings = {}      for gid in gids:          compound_name = project_code + ':' + gid          result = session.query(ProfileSetting).filter(              ProfileSetting.name == compound_name          ).first()          ...

在這個(gè)遍歷很多次的 for 里面，session.query(ProfileSetting) 被反復(fù)無(wú)效執(zhí)行了，然后 filter 這個(gè)屬性方法也被頻繁讀取和執(zhí)行，所以這里也可以被優(yōu)化。

總結(jié)下的問(wèn)題就是：

1. 數(shù)據(jù)庫(kù)的查詢(xún)沒(méi)有批量查詢(xún)；  2. ORM 的對(duì)象太多重復(fù)的生成，導(dǎo)致性能損耗；  3. 屬性讀取后沒(méi)有復(fù)用，導(dǎo)致在遍歷次數(shù)較大的循環(huán)體內(nèi)頻繁 getAttr，成本被放大；

那么對(duì)癥下藥就是：

def get_group_profile_settings(project_code, gids):          # 獲取 Mysql ORM 操作對(duì)象      ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))      session = get_postman_session()            # 批量查詢(xún) 并將 filter 提到循環(huán)之外      query_results = query_instance.filter(          ProfileSetting.name.in_(project_code + ':' + gid for gid in gids)      ).all()      # 對(duì)全部的查詢(xún)結(jié)果再單條處理      profile_settings = {}      for result in query_results:          if not result:              continue          resultresult = result.as_dict()          gid = result['name'].split(':')[1]          tag_indexes = result.get('tag_indexes')          profile_settings[gid] = {              'tag_indexes': tag_indexes,              'interval': result['interval'],              'status': result['status'],              'profile_machines': result['profile_machines'],              'thread_settings': result['thread_settings']          }              ...(省略)      return profile_settings

優(yōu)化后的火焰圖：

對(duì)比下優(yōu)化前的相同位置的火焰圖：

明顯的優(yōu)化點(diǎn)：優(yōu)化前的，最底部的 utils.py:get_group_profile_settings 和 數(shù)據(jù)庫(kù)相關(guān)的熱點(diǎn)大大縮減。

優(yōu)化效果

同一個(gè)項(xiàng)目的接口的響應(yīng)時(shí)長(zhǎng)從 37.6 s 優(yōu)化成 1.47s，具體的截圖：

優(yōu)化總結(jié)

如同一句名言：

如果一個(gè)數(shù)據(jù)結(jié)構(gòu)足夠優(yōu)秀，那么它是不需要多好的算法。

在優(yōu)化功能的時(shí)候，最快的優(yōu)化就是：去掉那個(gè)功能！

其次快就是調(diào)整那個(gè)功能觸發(fā)的 頻率 或者 復(fù)雜度！

從上到下，從用戶(hù)使用場(chǎng)景去考慮這個(gè)功能優(yōu)化方式，往往會(huì)帶來(lái)更加簡(jiǎn)單高效的結(jié)果，嘿嘿！

當(dāng)然很多時(shí)候我們是無(wú)法那么幸運(yùn)的，如果我們實(shí)在無(wú)法去掉或者調(diào)整，那么就發(fā)揮做程序猿的價(jià)值咯：Profile

針對(duì) Python 可以嘗試：cProflile + gprof2dot

而針對(duì) Go 可以使用: pprof + go-torch

很多時(shí)候看到的代碼問(wèn)題都不一定是真正的性能瓶頸，需要結(jié)合工具來(lái)客觀分析，這樣才能有效直擊痛點(diǎn)！

其實(shí)這個(gè) 1.47s，其實(shí)還不是最好的結(jié)果，還可以有更多優(yōu)化的空間，比如：

1.  前端渲染和呈現(xiàn)的方式，因?yàn)檎麄€(gè)表格是有很多數(shù)據(jù)組裝后再呈現(xiàn)的，響應(yīng)慢的單元格可以默認(rèn)先顯示 菊花，數(shù)據(jù)返回再更新；

2.  火焰圖看到還有挺多細(xì)節(jié)可以?xún)?yōu)化，可以替換請(qǐng)求數(shù)據(jù)的外部接口，比如再優(yōu)化徹底 GetAttr 相關(guān)的邏輯；

3.  更極端就是直接 Python 轉(zhuǎn) GO；

但是這些優(yōu)化已經(jīng)不是那么迫切了，因?yàn)檫@個(gè) 1.47s 是比較大型項(xiàng)目的優(yōu)化結(jié)果了，絕大部分的項(xiàng)目其實(shí)不到 1s 就能返回

再優(yōu)化可能付出更大成本，而結(jié)果可能也只是從 500ms 到 400ms 而已，結(jié)果并不那么高性?xún)r(jià)比。

所以我們一定要時(shí)刻清晰自己優(yōu)化的目標(biāo)，時(shí)刻考慮 投入產(chǎn)出比，在有限的時(shí)間做出比較高的價(jià)值（如果有空閑時(shí)間當(dāng)然可以盡情干到底）

感謝各位的閱讀，以上就是“如何理解Python接口優(yōu)化”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)如何理解Python接口優(yōu)化這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

網(wǎng)頁(yè)題目：如何理解Python接口優(yōu)化
標(biāo)題路徑：http://bm7419.com/article2/ipoeoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、自適應(yīng)網(wǎng)站、電子商務(wù)、商城網(wǎng)站、網(wǎng)站設(shè)計(jì)公司、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)