www.久久久久|狼友网站av天堂|精品国产无码a片|一级av色欲av|91在线播放视频|亚洲无码主播在线|国产精品草久在线|明星AV网站在线|污污内射久久一区|婷婷综合视频网站

當(dāng)前位置:首頁 > 公眾號(hào)精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]前言這篇文章的主題是記錄一次Python程序的性能優(yōu)化,在優(yōu)化的過程中遇到的問題,以及如何去解決的。為大家提供一個(gè)優(yōu)化的思路,首先要聲明的一點(diǎn)是,我的方式不是唯一的,大家在性能優(yōu)化之路上遇到的問題都絕對(duì)不止一個(gè)解決方案。如何優(yōu)化首先大家要明確的一點(diǎn)是,脫離需求談優(yōu)化都是耍流氓,所...



前言

這篇文章的主題是記錄一次 Python 程序的性能優(yōu)化,在優(yōu)化的過程中遇到的問題,以及如何去解決的。為大家提供一個(gè)優(yōu)化的思路,首先要聲明的一點(diǎn)是,我的方式不是唯一的,大家在性能優(yōu)化之路上遇到的問題都絕對(duì)不止一個(gè)解決方案。

如何優(yōu)化

首先大家要明確的一點(diǎn)是,脫離需求談優(yōu)化都是耍流氓,所以有誰跟你說在xx機(jī)器上實(shí)現(xiàn)了百萬并發(fā),基本上可以認(rèn)為是不懂裝懂了,單純的并發(fā)數(shù)完全是無意義的。其次,我們優(yōu)化之前必須要有一個(gè)目標(biāo),需要優(yōu)化到什么程度,沒有明確目標(biāo)的優(yōu)化是不可控的。再然后,我們必須明確的找出性能瓶頸在哪里,而不能漫無目的的一通亂搞。


需求描述

這個(gè)項(xiàng)目是我在上家公司負(fù)責(zé)一個(gè)單獨(dú)的模塊,本來是集成在主站代碼中的,后來因?yàn)椴l(fā)太大,為了防止出現(xiàn)問題后拖累主站服務(wù),所有由我一個(gè)人負(fù)責(zé)拆分出來。對(duì)這個(gè)模塊的拆分要求是,壓力測試 QPS 不能低于3萬,數(shù)據(jù)庫負(fù)載不能超過50%,服務(wù)器負(fù)載不能超過70%,單次請(qǐng)求時(shí)長不能超過70ms,錯(cuò)誤率不能超過5%。環(huán)境的配置如下:服務(wù)器:4核8G內(nèi)存,CentOS7系統(tǒng),SSD 硬盤
數(shù)據(jù)庫:MySQL 5.7,最大連接數(shù) 800
緩存: Redis,1G 容量。
以上環(huán)境都是購買自騰訊云的服務(wù)。壓測工具:locust,使用騰訊的彈性伸縮實(shí)現(xiàn)分布式的壓測。需求描述如下:用戶進(jìn)入首頁,從數(shù)據(jù)庫中查詢是否有合適的彈窗配置,如果沒有,則繼續(xù)等待下一次請(qǐng)求、如果有合適的配置,則返回給前端。這里開始則有多個(gè)條件分支,如果用戶點(diǎn)擊了彈窗,則記錄用戶點(diǎn)擊,并且在配置的時(shí)間內(nèi)不再返回配置,如果用戶未點(diǎn)擊,則24小時(shí)后繼續(xù)返回本次配置,如果用戶點(diǎn)擊了,但是后續(xù)沒有配置了,則接著等待下一次。

重點(diǎn)分析

根據(jù)需求,我們知道了有幾個(gè)重要的點(diǎn),1、需要找出合適用戶的彈窗配置,2、需要記錄用戶下一次返回配置的時(shí)間并記錄到數(shù)據(jù)庫中,3、需要記錄用戶對(duì)返回的配置執(zhí)行了什么操作并記錄到數(shù)據(jù)庫中。

調(diào)優(yōu)

我們可以看到,上述三個(gè)重點(diǎn)都存在數(shù)據(jù)庫的操作,不只有讀庫,還有寫庫操作。從這里我們可以看到如果不加緩存的話,所有的請(qǐng)求都?jí)旱綌?shù)據(jù)庫,勢必會(huì)占滿全部連接數(shù),出現(xiàn)拒絕訪問的錯(cuò)誤,同時(shí)因?yàn)?SQL 執(zhí)行過慢,導(dǎo)致請(qǐng)求無法及時(shí)返回。所以,我們首先要做的就是講寫庫操作剝離開來,提升每一次請(qǐng)求響應(yīng)速度,優(yōu)化數(shù)據(jù)庫連接。整個(gè)系統(tǒng)的架構(gòu)圖如下:



將寫庫操作放到一個(gè)先進(jìn)先出的消息隊(duì)列中來做,為了減少復(fù)雜度,使用了Redis 的 list 來做這個(gè)消息隊(duì)列。然后進(jìn)行壓測,結(jié)果如下:QPS 在 6000 左右 502 錯(cuò)誤大幅上升至 30%,服務(wù)器 CPU 在 60%-70% 之間來回跳動(dòng),數(shù)據(jù)庫連接數(shù)被占滿 TCP 連接數(shù)為 6000 左右,很明顯,問題還是出在數(shù)據(jù)庫,經(jīng)過排查 SQL 語句,查詢到原因就是找出合適用戶的配置操作時(shí)每次請(qǐng)求都要讀取數(shù)據(jù)庫所導(dǎo)致的連接數(shù)被用完。因?yàn)槲覀兊倪B接數(shù)只有 800,一旦請(qǐng)求過多,勢必會(huì)導(dǎo)致數(shù)據(jù)庫瓶頸。好了,問題找到了,我們繼續(xù)優(yōu)化,更新的架構(gòu)如下:


我們將全部的配置都加載到緩存中,只有在緩存中沒有配置的時(shí)候才會(huì)去讀取數(shù)據(jù)庫。接下來我們?cè)俅螇簻y,結(jié)果如下:


QPS 壓到 2萬左右的時(shí)候就上不去了,服務(wù)器 CPU 在 60%-80% 之間跳動(dòng),數(shù)據(jù)庫連接數(shù)為300個(gè)左右,每秒TPC連接數(shù)為1.5萬左右。這個(gè)問題是困擾我比較久的一個(gè)問題,因?yàn)槲覀兛梢钥吹剑覀?萬的 QPS,但是TCP 連接數(shù)卻并沒有達(dá)到2萬,我猜測,TCP連接數(shù)就是引發(fā)瓶頸的問題,但是因?yàn)槭裁丛蛩l(fā)的暫時(shí)無法找出來。


這個(gè)時(shí)候猜測,既然是無法建立 TCP 連接,是否有可能是服務(wù)器限制了 socket 連接數(shù),驗(yàn)證猜測,我們看一下,在終端輸入 ulimit -n 命令,顯示的結(jié)果為65535,看到這里,覺得 socket 連接數(shù)并不是限制我們的原因,為了驗(yàn)證猜測,將 socket 連接數(shù)調(diào)大為100001.再次進(jìn)行壓測,結(jié)果如下:QPS壓到2.2萬左右的時(shí)候就上不去了,服務(wù)器cpu在60%-80%之間跳動(dòng),數(shù)據(jù)庫連接數(shù)為300個(gè)左右,每秒 TCP 連接數(shù)為1.7萬左右。雖然有一點(diǎn)提升,但是并沒有實(shí)質(zhì)性的變化,接下來的幾天時(shí)間,我發(fā)現(xiàn)都無法找到優(yōu)化的方案,那幾天確實(shí)很難受,找不出來優(yōu)化的方案,過了幾天,再次將問題梳理了一遍,發(fā)現(xiàn),雖然socket連接數(shù)足夠,但是并沒有全部被用上,猜測,每次請(qǐng)求過后,tcp連接并沒有立即被釋放,導(dǎo)致socket無法重用。經(jīng)過查找資料,找到了問題所在,
TCP 鏈接在經(jīng)過四次握手結(jié)束連接后并不會(huì)立即釋放,而是處于 timewait 狀態(tài),會(huì)等待一段時(shí)間,以防止客戶端后續(xù)的數(shù)據(jù)未被接收。
好了,問題找到了,我們要接著優(yōu)化,首先想到的就是調(diào)整 TCP 鏈接結(jié)束后等待時(shí)間,但是 Linux 并沒有提供這一內(nèi)核參數(shù)的調(diào)整,如果要改,必須要自己重新編譯內(nèi)核,幸好還有另一個(gè)參數(shù) net.ipv4.tcp_max_tw_buckets, timewait 的數(shù)量,默認(rèn)是180000。我們調(diào)整為 6000,然后打開 timewait 快速回收,和開啟重用,完整的參數(shù)優(yōu)化如下:
#timewait 的數(shù)量,默認(rèn)是 180000。net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
#啟用 timewait 快速回收。net.ipv4.tcp_tw_recycle = 1#開啟重用。允許將 TIME-WAIT sockets 重新用于新的 TCP 連接。net.ipv4.tcp_tw_reuse = 1 我們?cè)俅螇簻y,結(jié)果顯示:QPS 5萬,服務(wù)器 CPU 70%,數(shù)據(jù)庫連接正常,TCP 連接正常,響應(yīng)時(shí)間平均為 60ms,錯(cuò)誤率為 0%。

結(jié)語

到此為止,整個(gè)服務(wù)的開發(fā)、調(diào)優(yōu)、和壓測就結(jié)束了?;仡欉@一次調(diào)優(yōu),得到了很多經(jīng)驗(yàn),最重要的是,深刻理解了web開發(fā)不是一個(gè)獨(dú)立的個(gè)體,而是網(wǎng)絡(luò)、數(shù)據(jù)庫、編程語言、操作系統(tǒng)等多門學(xué)科結(jié)合的工程實(shí)踐,這就要求web開發(fā)人員有牢固的基礎(chǔ)知識(shí),否則出現(xiàn)了問題還不知道怎么分析查找。ps:服務(wù)端開啟了 tcp_tw_recycle 和 tcp_tw_reuse是會(huì)導(dǎo)致一些問題的,我們?yōu)榱藘?yōu)化選擇犧牲了一部分,獲得另一部分,這也是我們要明確的,具體的問題可以查看耗子叔的文章TCP 的那些事兒(上)


本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動(dòng)力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉