建站
咨詢
售后
建站咨詢
新聞中心
本篇內容主要講解“Python Web接口優(yōu)化的方法教程”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Python Web接口優(yōu)化的方法教程”吧!
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網綜合服務，包含不限于成都網站設計、成都網站建設、外貿網站建設、上杭網絡推廣、微信小程序、上杭網絡營銷、上杭企業(yè)策劃、上杭品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供上杭建站搭建服務，24小時服務熱線：13518219792，官方網址：www.cdcxhl.com
背景
我們負責的一個業(yè)務平臺，有次在發(fā)現(xiàn)設置頁面的加載特別特別地慢，簡直就是令人發(fā)指
讓用戶等待 36s 肯定是不可能的，于是我們就要開啟優(yōu)化之旅了。
投石問路
既然是網站的響應問題，可以通過 Chrome 這個強大的工具幫助我們快速找到優(yōu)化方向。
通過 Chrome 的 Network 除了可以看到接口請求耗時之外，還能看到一個時間的分配情況，選擇一個配置沒有那么多的項目，簡單請求看看：
雖然只是一個只有三條記錄的項目，加載項目設置都需要 17s，通過 Timing, 可以看到總的請求共耗時 17.67s ，但有 17.57s 是在 Waiting(TTFB) 狀態(tài)。
TTFB 是 Time to First Byte 的縮寫，指的是瀏覽器開始收到服務器響應數據的時間（后臺處理時間+重定向時間），是反映服務端響應速度的重要指標。
Profile 火焰圖 + 代碼調優(yōu)
那么大概可以知道優(yōu)化的大方向是在后端接口處理上面，后端代碼是 Python + Flask 實現(xiàn)的，先不盲猜，直接上 Profile：
第一波優(yōu)化：功能交互重新設計
說實話看到這段代碼是絕望的：完全看不出什么？只是看到很多 gevent 和 Threading，因為太多協(xié)程或者線程？
這時候一定要結合代碼來分析（為了簡短篇幅，參數部分用 “...” 代替）：
?def get_max_cpus(project_code, gids): """ """ ... # 再定義一個獲取 cpu 的函數 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 # 啟動線程批量請求 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通過代碼可以看到，為了更加快速獲取 gids 所有的 cpu_max 數據，為每個 gid 分配一個線程去請求，最終再返回最大值。
這里會出現(xiàn)兩個問題：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)
在一個 web api 做線程的 創(chuàng)建 和 銷毀 是有很大成本的，因為接口會頻繁被觸發(fā)，線程的操作也會頻繁發(fā)生，應該盡可能使用線程池之類的，降低系統(tǒng)花銷；
該請求是加載某個 gid (群組) 下面的機器過去 7 天的 CPU 最大值，可以簡單拍腦袋想下，這個值不是實時值也不是一個均值，而是一個最大值，很多時候可能并沒有想象中那么大價值；
既然知道問題，那就有針對性的方案：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)
調整功能設計，不再默認加載 CPU 最大值，換成用戶點擊加載（一來降低并發(fā)的可能，二來不會影響整體）；
因為 1 的調整，去掉多線程實現(xiàn)；
再看第一波優(yōu)化后的火焰圖：
這次看的火焰圖雖然還有很大的優(yōu)化空間，但起碼看起來有點正常的樣子了。
第二波優(yōu)化：MySQL 操作優(yōu)化處理
我們再從頁面標記處（接口邏輯處）放大火焰圖觀察：
看到好大一片操作都是由 utils.py:get_group_profile_settings 這個函數引起的數據庫操作熱點。
同理，也是需要通過代碼分析：
def get_group_profile_settings(project_code, gids): # 獲取 Mysql ORM 操作對象 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 ，第一個反應就是 索引問題，所以優(yōu)先去看看數據庫的索引情況，如果有索引的話應該不會是瓶頸：
很奇怪這里明明已經有了索引了，為什么速度還是這個鬼樣子呢！
正當毫無頭緒的時候，突然想起在 第一波優(yōu)化 的時候， 發(fā)現(xiàn) gid（群組）越多的影響越明顯，然后看回上面的代碼，看到那句：
for gid in gids: ...
我仿佛明白了什么。
這里是每個 gid 都去查詢一次數據庫，而項目經常有 20 ~ 50+ 個群組，那肯定直接爆炸了。
其實 Mysql 是支持單字段多值的查詢，而且每條記錄并沒有太多的數據，我可以嘗試下用 Mysql 的 OR 語法，除了避免多次網絡請求，還能避開那該死的 for
正當我想事不宜遲直接搞起的時候，余光瞥見在剛才的代碼還有一個地方可以優(yōu)化，那就是：
看到這里，熟悉的朋友大概會明白是怎么回事。
GetAttr 這個方法是Python 獲取對象的 方法/屬性 時候會用到，雖然不可不用，但是如果在使用太過頻繁也會有一定的性能損耗。
結合代碼一起來看：
def get_group_profile_settings(project_code, gids): # 獲取 Mysql ORM 操作對象 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() ...在這個遍歷很多次的 for 里面，session.query(ProfileSetting) 被反復無效執(zhí)行了，然后 filter 這個屬性方法也被頻繁讀取和執(zhí)行，所以這里也可以被優(yōu)化。
總結下的問題就是：
1. 數據庫的查詢沒有批量查詢；
2. ORM 的對象太多重復的生成，導致性能損耗；
3. 屬性讀取后沒有復用，導致在遍歷次數較大的循環(huán)體內頻繁 getAttr，成本被放大；
那么對癥下藥就是：
def get_group_profile_settings(project_code, gids): # 獲取 Mysql ORM 操作對象 ProfileSetting = unpurview(sandman.endpoint_class('profile_settings')) session = get_postman_session() # 批量查詢 并將 filter 提到循環(huán)之外 query_results = query_instance.filter( ProfileSetting.name.in_(project_code + ':' + gid for gid in gids) ).all() # 對全部的查詢結果再單條處理 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)化后的火焰圖：
對比下優(yōu)化前的相同位置的火焰圖：
明顯的優(yōu)化點：優(yōu)化前的，最底部的 utils.py:get_group_profile_settings 和 數據庫相關的熱點大大縮減。
優(yōu)化效果
同一個項目的接口的響應時長從 37.6 s 優(yōu)化成 1.47s，具體的截圖：
優(yōu)化總結
如同一句名言：
如果一個數據結構足夠優(yōu)秀，那么它是不需要多好的算法。
在優(yōu)化功能的時候，最快的優(yōu)化就是：去掉那個功能！
其次快就是調整那個功能觸發(fā)的 頻率 或者 復雜度！
從上到下，從用戶使用場景去考慮這個功能優(yōu)化方式，往往會帶來更加簡單高效的結果，嘿嘿！
當然很多時候我們是無法那么幸運的，如果我們實在無法去掉或者調整，那么就發(fā)揮做程序猿的價值咯：Profile
針對 Python 可以嘗試：cProflile + gprof2dot
而針對 Go 可以使用: pprof + go-torch
很多時候看到的代碼問題都不一定是真正的性能瓶頸，需要結合工具來客觀分析，這樣才能有效直擊痛點！
其實這個 1.47s，其實還不是最好的結果，還可以有更多優(yōu)化的空間，比如：
前端渲染和呈現(xiàn)的方式，因為整個表格是有很多數據組裝后再呈現(xiàn)的，響應慢的單元格可以默認先顯示 菊花，數據返回再更新；
火焰圖看到還有挺多細節(jié)可以優(yōu)化，可以替換請求數據的外部接口，比如再優(yōu)化徹底 GetAttr 相關的邏輯；
更極端就是直接 Python 轉 GO；
但是這些優(yōu)化已經不是那么迫切了，因為這個 1.47s 是比較大型項目的優(yōu)化結果了，絕大部分的項目其實不到 1s 就能返回
再優(yōu)化可能付出更大成本，而結果可能也只是從 500ms 到 400ms 而已，結果并不那么高性價比。
所以我們一定要時刻清晰自己優(yōu)化的目標，時刻考慮 投入產出比，在有限的時間做出比較高的價值（如果有空閑時間當然可以盡情干到底）
到此，相信大家對“Python Web接口優(yōu)化的方法教程”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
新聞名稱：PythonWeb接口優(yōu)化的方法教程
本文路徑：http://www.ef60e0e.cn/article/peojgp.html
