知道這些性能優(yōu)化手段，工資起碼提升一倍
1.什么是性能?性能指標(biāo)有哪些？
計(jì)算機(jī)的性能，其實(shí)和我們干體力勞動(dòng)很像，好比是我們要搬東西。對(duì)于計(jì)算機(jī)的性能，我們需要有個(gè)標(biāo)準(zhǔn)來衡量。這個(gè)標(biāo)準(zhǔn)中主要有兩個(gè)指標(biāo)。第一個(gè)是響應(yīng)時(shí)間（Response time）或者叫執(zhí)行時(shí)間（Execution time）。想要提升響應(yīng)時(shí)間這個(gè)性能指標(biāo)，你可以理解為讓計(jì)算機(jī)“跑得更快”
? ? ? ? 第二個(gè)是吞吐率（Throughput）或者帶寬（Bandwidth），想要提升這個(gè)指標(biāo)，你可以理解為讓計(jì)算機(jī)“搬得更多”。
所以說，響應(yīng)時(shí)間指的就是，我們執(zhí)行一個(gè)程序，到底需要花多少時(shí)間?；ǖ臅r(shí)間越少， 自然性能就越好。而吞吐率是指我們?cè)谝欢ǖ臅r(shí)間范圍內(nèi)，到底能處理多少事情。這里的“事情”，在計(jì)算機(jī)里就是處理的數(shù)據(jù)或者執(zhí)行的程序指令。和搬東西來做對(duì)比，如果我們的響應(yīng)時(shí)間短，跑得快，我們可以來回多跑幾趟多搬幾趟。所以說，縮短程序的響應(yīng)時(shí)間，一般來說都會(huì)提升吞吐率。除了縮短響應(yīng)時(shí)間，我們還有別的方法嗎？當(dāng)然有，比如說，我們還可以多找?guī)讉€(gè)人一起來搬，這就類似現(xiàn)代的服務(wù)器都是 8 核、16 核的。人多力量大，同時(shí)處理數(shù)據(jù)，在單位時(shí)間內(nèi)就可以處理更多數(shù)據(jù)，吞吐率自然也就上去了。提升吞吐率的辦法有很多。大部分時(shí)候，我們只要多加一些機(jī)器，多堆一些硬件就好了。但是響應(yīng)時(shí)間的提升卻沒有那么容易，因?yàn)?CPU 的性能提升其實(shí)在 10 年前就處于“擠牙膏”的狀態(tài)了，所以我們得慎重地來分析對(duì)待。
下面我們具體來看。我們一般把性能，定義成響應(yīng)時(shí)間的倒數(shù)，也就是：性能 = 1/ 響應(yīng)時(shí)間這樣一來，響應(yīng)時(shí)間越短，性能的數(shù)值就越大。同樣一個(gè)程序，在 Intel 最新的 CPU Coffee Lake 上，只需要 30s 就能運(yùn)行完成，而在 5 年前 CPU Sandy Bridge 上，需要 1min 才能完成。那么我們自然可以算出來，Coffee Lake 的性能是 1/30，Sandy Bridge 的性能是 1/60，兩個(gè)的性能比為 2。于是，我們就可以說，Coffee Lake 的性能是 Sandy Bridge 的 2 倍。過去幾年流行的手機(jī)跑分軟件，就是把多個(gè)預(yù)設(shè)好的程序在手機(jī)上運(yùn)行，然后根據(jù)運(yùn)行需要的時(shí)間，算出一個(gè)分?jǐn)?shù)來給出手機(jī)的性能評(píng)估。而在業(yè)界，各大 CPU 和服務(wù)器廠商組織了一個(gè)叫做?SPEC（Standard Performance Evaluation Corporation）的第三方機(jī)構(gòu)，專門用來指定各種“跑分”的規(guī)則。
2.如果性能不達(dá)標(biāo)怎么辦？
使用Profiler性能分析器首先確定性能瓶頸出現(xiàn)在哪里，定位性能問題出現(xiàn)的根本原因，按照具體原因去做優(yōu)化。
通常來說，性能問題大致出現(xiàn)在兩個(gè)方面：
1.細(xì)節(jié)不夠好(資源問題、插件問題、代碼寫法問題)
2.結(jié)構(gòu)不夠好(框架問題、底層API問題)
細(xì)節(jié)問題解決成本低，可以獨(dú)立調(diào)整，對(duì)其他部分影響小，可以批量解決。
結(jié)構(gòu)問題解決成本高，牽一發(fā)動(dòng)全身，對(duì)其他部分影響大，需要大修、大測(cè)。
由于游戲整體是由各個(gè)細(xì)節(jié)組成的，所以當(dāng)細(xì)節(jié)做的不夠好時(shí)，整體也會(huì)顯現(xiàn)出問題。
反之當(dāng)結(jié)構(gòu)不夠好時(shí)，細(xì)節(jié)即使做的很好，游戲整體表現(xiàn)出的性能也不會(huì)太好，兩者是相輔相成的。
我的建議是：用嚴(yán)格認(rèn)真的態(tài)度控制細(xì)節(jié)，用豐富的經(jīng)驗(yàn)積累出可靠的結(jié)構(gòu)。
前者靠態(tài)度，后者靠經(jīng)驗(yàn)。當(dāng)我們經(jīng)驗(yàn)不多時(shí)，應(yīng)該依靠態(tài)度嚴(yán)控細(xì)節(jié)，當(dāng)我們經(jīng)驗(yàn)足夠時(shí)，兩方面都要兼顧。
調(diào)優(yōu)策略：追求基于滿足訴求的精度條件下的性能提升。但是，如果性能已經(jīng)達(dá)到無法接受的程度，那么就先解決性能，處理到可接受為止。
精度調(diào)優(yōu)過程中導(dǎo)致性能惡化，或者性能調(diào)優(yōu)過程中導(dǎo)致精度惡化，記住兩點(diǎn)：
1、千萬不要兜圈子，不要精度差了搞精度，性能差了又搞性能。
2、有階段成果后，后續(xù)的嘗試和修改一定要分步驟執(zhí)行，做好記錄
3.訓(xùn)練服務(wù)器的演示及簡(jiǎn)介
Atlas 800 訓(xùn)練服務(wù)器（型號(hào)9000）是基于華為鯤鵬920+昇騰910處理器的AI訓(xùn)練服務(wù)器，實(shí)現(xiàn)完全自主可控，廣泛應(yīng)用于深度學(xué)習(xí)模型開發(fā)和AI訓(xùn)練服務(wù)場(chǎng)景。該服務(wù)器面向公有云、互聯(lián)網(wǎng)、運(yùn)營(yíng)商、政府、交通、金融、高校、電力等領(lǐng)域，具有高計(jì)算密度、高能效比、高網(wǎng)絡(luò)帶寬、易擴(kuò)展、易管理等優(yōu)點(diǎn)，支持單機(jī)和整機(jī)柜銷售，支持風(fēng)冷和液冷應(yīng)用，滿足企業(yè)機(jī)房部署和大規(guī)模數(shù)據(jù)中心集群部署。
計(jì)算產(chǎn)品3D展示 (huawei.com)
大家可以使用上面的地址進(jìn)行3D模型預(yù)覽及展示，可以看這個(gè)服務(wù)器的構(gòu)造及拆解組件，體驗(yàn)感十足。
這個(gè)性能分析在昇騰全棧AI軟硬件平臺(tái)主要體現(xiàn)在標(biāo)記的異構(gòu)計(jì)算架構(gòu)部分，釋放硬件的算力。
4.訓(xùn)練執(zhí)行的過程是什么樣的？
OBS資源圖里有很多細(xì)分的圖表，其實(shí)不需要全部記住，因?yàn)槊總€(gè)指標(biāo)的變化都不是獨(dú)立的，是與其他指標(biāo)關(guān)聯(lián)的
1、每秒點(diǎn)擊數(shù)
每秒點(diǎn)擊數(shù)（Hits per Second）統(tǒng)計(jì)的是運(yùn)行場(chǎng)景過程中，虛擬用戶每秒向Web服務(wù)器提交的HTTP請(qǐng)求數(shù)。該指標(biāo)經(jīng)常與其他指標(biāo)結(jié)合進(jìn)行分析
2、吞吐量
吞吐量（Throughput）統(tǒng)計(jì)場(chǎng)景運(yùn)行過程中服務(wù)器的每秒吞吐量，單位是字節(jié)，表示虛擬用戶在任何給定的每一秒內(nèi)，從服務(wù)器獲得的數(shù)據(jù)量。通過該指標(biāo)可以看出服務(wù)器在流量方面的處理能力以及是否存在瓶頸，正常情況下，吞吐量與TPS圖的變化基本一致。若壓力增大時(shí)，吞吐量的曲線增加到一定程度后變化緩慢，甚至平坦，則很可能是網(wǎng)絡(luò)出現(xiàn)帶寬瓶頸。不論是吞吐量，還是TPS都非常不穩(wěn)定，尤其是TPS，通過率比較低
3、HTTP狀態(tài)碼概要
HTTP狀態(tài)碼概要（HTTP Status Code Summary）統(tǒng)計(jì)場(chǎng)景運(yùn)行過程中，從Web服務(wù)器返回的HTTP狀態(tài)代碼數(shù)，返回的都是200狀態(tài)碼，說明在HTTP返回層面上是成功的
4、每秒HTTP響應(yīng)數(shù)
每秒HTTP響應(yīng)數(shù)（HTTP Responses per Second）統(tǒng)計(jì)運(yùn)行場(chǎng)景過程中，每秒從Web服務(wù)器返回的不同HTTP狀態(tài)碼的數(shù)量。一般和每秒點(diǎn)擊量相同，如果服務(wù)器的響應(yīng)數(shù)小于點(diǎn)擊量，那么說明服務(wù)器無法應(yīng)答，超過負(fù)載的鏈接請(qǐng)求
5、連接數(shù)
連接數(shù)（Connections）統(tǒng)計(jì)場(chǎng)景運(yùn)行過程中，每個(gè)時(shí)間點(diǎn)打開的TCP/IP連接數(shù)。例如，當(dāng)連接數(shù)dadao 穩(wěn)定狀態(tài)而事務(wù)響應(yīng)時(shí)間迅速增大時(shí)，添加連接可以使用性能得到極大提高
6、每秒連接數(shù)
每秒連接數(shù)（Connections Per Second）統(tǒng)計(jì)新建的連接數(shù)和關(guān)閉的連接數(shù)，方便了解每秒對(duì)服務(wù)器產(chǎn)生連接的數(shù)量。同時(shí)連接數(shù)越多，說明服務(wù)器的連接池越大，當(dāng)連接數(shù)隨著負(fù)載上升而停止時(shí)，說明系統(tǒng)的連接池已滿，通常這個(gè)時(shí)候服務(wù)器會(huì)返回504錯(cuò)誤
7、每秒重試次數(shù)
每秒重試次數(shù)圖顯示在場(chǎng)景運(yùn)行的每一秒內(nèi)，服務(wù)器嘗試的連接次數(shù)。在下列情況下將重試服務(wù)器連接
初始連接未經(jīng)授權(quán)
要求代理服務(wù)器身份驗(yàn)證
服務(wù)器關(guān)閉了初始連接
初始連接無法連接到服務(wù)器
服務(wù)器最初無法解析負(fù)載生成器的IP地址
8、每秒SSL連接數(shù)
每秒SSL連接數(shù)圖顯示在場(chǎng)景運(yùn)行的每一秒內(nèi)，重新使用的SSL連接數(shù)。當(dāng)對(duì)安全服務(wù)器打開TCP/IP連接后，瀏覽器打開SSL連接。因?yàn)樾陆⊿SL連接需要消耗大量的資源，所以應(yīng)該盡量減少打開新的SSL連接。建立新SSL連接后，應(yīng)該重復(fù)使用該連接。每個(gè)虛擬用戶的新SSL連接數(shù)不應(yīng)該超過一個(gè)。理想情況下，每秒都應(yīng)該只有很少量的新TCP/IP和SSL連接.
5.將整網(wǎng)訓(xùn)練階段進(jìn)行分段，分析性能影響
1).數(shù)據(jù)讀取階段：主要影響在HOST側(cè)
2).數(shù)據(jù)預(yù)處理階段：HOST和DEVICE都可能涉及
3).訓(xùn)練后處理階段：HOST和DEVICE都可能涉及
相關(guān)文檔Log/Summary_昇騰CANN社區(qū)版(5.0.3 alpha 001)(訓(xùn)練)_TensorFlow模型遷移和訓(xùn)練_手工遷移和訓(xùn)練_更多特性_華為云 (huaweicloud.com)
4）.訓(xùn)練執(zhí)行階段：主要影響在DEVICE側(cè)
6.打開Profiling前，確認(rèn)當(dāng)前源碼狀態(tài)(確認(rèn)當(dāng)前源碼處在手工遷移后的狀態(tài))
原始的代碼：
sess=tf.Session()
自動(dòng)遷移后的代碼：
sess = tf.Session(config=npu_config_proto())
手工遷移后的代碼：
config = tf.ConfigProto()
custom_op = config.graph_options.rewrite_options.custom_optimizers.add()
custom_op.name = "NpuOptimizer"
config.graph_options.rewrite_options.remapping = RewriterConfig.OFF
config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF
sess = tf.Session(config=config)設(shè)置Profiling開關(guān)，打開Profiling
手工遷移后的代碼：
config = tf.ConfigProto()
custom_op = config.graph_options.rewrite_options.custom_optimizers.add()
custom_op.name = "NpuOptimizer"
config.graph_options.rewrite_options.remapping = RewriterConfig.OFF
config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF
sess = tf.Session(config=config)
設(shè)置profiling后的代碼：
config = tf.ConfigProto()
custom_op = config.graph_options.rewrite_options.custom_optimizers.add()
custom_op.name = "NpuOptimizer"
custom_op.parameter_map["profiling_mode"].b = True
custom_op.parameter_map["profiling_options"].s =
tf.compat.as_bytes('{"output":"/mypath/output","task_trace":"on","training_trace":"on","aicpu":"on","fp_point":"","bp_point":""}')
config.graph_options.rewrite_options.remapping = RewriterConfig.OFF
config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF
sess = tf.Session(config=config)
操作手冊(cè)請(qǐng)參考功能介紹_昇騰CANN社區(qū)版(5.0.3 alpha 001)(訓(xùn)練)_開發(fā)輔助工具_(dá)Profiling工具使用指南_概述_華為云 (huaweicloud.com)
7.總結(jié)：遇到性能問題時(shí)，推薦的debug順序和手段是什么樣的？
core dump的調(diào)試
首先說一下core的解決思路，主要是如下幾點(diǎn)：
gdb及debug log定位，發(fā)現(xiàn)作用不大。
如何重現(xiàn)bug？
構(gòu)造高并發(fā)壓力測(cè)試系統(tǒng)。
構(gòu)造穩(wěn)定的異常請(qǐng)求。
使用TC(traffic control)工具來構(gòu)造弱網(wǎng)絡(luò)環(huán)境，但是轉(zhuǎn)念一想，弱網(wǎng)絡(luò)環(huán)境導(dǎo)致的結(jié)果是什么？顯然是網(wǎng)絡(luò)請(qǐng)求的各種異常啊,所以還不如直接構(gòu)造各種異常請(qǐng)求來復(fù)現(xiàn)問題。于是準(zhǔn)備構(gòu)造測(cè)試工具和環(huán)境，需要滿足兩個(gè)條件：
并發(fā)性能強(qiáng)，能夠同時(shí)發(fā)送數(shù)萬甚至數(shù)十萬級(jí)以上qps。
請(qǐng)求需要一定概率的異常。特別是TCP握手及SSL握手階段，需要異常中止。
WRK壓力測(cè)試工具
由于高并發(fā)流量時(shí)才可能出core，所以首先就需要找一個(gè)性能強(qiáng)大的壓測(cè)工具。
WRK是一款非常優(yōu)秀的開源HTTP壓力測(cè)試工具，采用多線程 + 異步事件驅(qū)動(dòng)的框架，其中事件機(jī)制使用了redis的ae事件框架，協(xié)議解析使用了nginx的相關(guān)代碼。
相比ab（apache bench）等傳統(tǒng)壓力測(cè)試工具的優(yōu)點(diǎn)就是性能好，基本上單臺(tái)機(jī)器發(fā)送幾百萬pqs,打滿網(wǎng)卡都沒有問題。
wrk的缺點(diǎn)就是只支持HTTP類協(xié)議，不支持其他協(xié)議類測(cè)試，比如protobuf，另外數(shù)據(jù)顯示也不是很方便。
nginx的測(cè)試用法：wrk -t500 -c2000 -d30s https://127.0.0.1:8443/index.html
linux世界有許多非常好用的性能分析工具，我挑選幾款最常用的簡(jiǎn)單介紹下：
1. [perf](Perf Wiki)應(yīng)該是最全面最方便的一個(gè)性能檢測(cè)工具。由linux內(nèi)核攜帶并且同步更新，基本能滿足日常使用。**推薦大家使用**。
2. oprofile，我覺得是一個(gè)較過時(shí)的性能檢測(cè)工具了，基本被perf取代，命令使用起來也不太方便。比如opcontrol --no-vmlinux , opcontrol --init等命令啟動(dòng)，然后是opcontrol --start， opcontrol --dump， opcontrol -h停止，opreport查看結(jié)果等，一大串命令和參數(shù)。有時(shí)候使用還容易忘記初始化，數(shù)據(jù)就是空的。
3. gprof主要是針對(duì)應(yīng)用層程序的性能分析工具，缺點(diǎn)是需要重新編譯程序，而且對(duì)程序性能有一些影響。不支持內(nèi)核層面的一些統(tǒng)計(jì)，優(yōu)點(diǎn)就是應(yīng)用層的函數(shù)性能統(tǒng)計(jì)比較精細(xì)，接近我們對(duì)日常性能的理解，比如各個(gè)函數(shù)時(shí)間的運(yùn)行時(shí)間，，函數(shù)的調(diào)用次數(shù)等，很人性易讀。
4. systemtap 其實(shí)是一個(gè)運(yùn)行時(shí)程序或者系統(tǒng)信息采集框架，主要用于動(dòng)態(tài)追蹤，當(dāng)然也能用做性能分析，功能最強(qiáng)大，同時(shí)使用也相對(duì)復(fù)雜。不是一個(gè)簡(jiǎn)單的工具，可以說是一門動(dòng)態(tài)追蹤語(yǔ)言。如果程序出現(xiàn)非常麻煩的性能問題時(shí)，推薦使用 systemtap。
這里再多介紹一下perf命令，tlinux系統(tǒng)上默認(rèn)都有安裝，比如通過perf top就能列舉出當(dāng)前系統(tǒng)或者進(jìn)程的熱點(diǎn)事件，函數(shù)的排序。
perf record能夠紀(jì)錄和保存系統(tǒng)或者進(jìn)程的性能事件，用于后面的分析，比如火焰圖。
調(diào)試BUG是一次非常難得的學(xué)習(xí)機(jī)會(huì)，不要把它看成是負(fù)擔(dān)。不管是線上還是線下，能夠主動(dòng)地，高效地追查BUG特別是有難度的BUG，對(duì)自己來說一次非常寶貴的學(xué)習(xí)機(jī)會(huì)。面對(duì)這么好的學(xué)習(xí)機(jī)會(huì)，自然要充滿熱情，要如饑似渴，回首一看，如果不是因?yàn)檫@個(gè)BUG，我也不會(huì)對(duì)一些工具有更深入地了解和使用，也就不會(huì)有這篇文檔的產(chǎn)生。
不管什么樣的BUG，隨著時(shí)間的推移，肯定是能夠解決的。這樣想想，其實(shí)會(huì)輕松很多，特別是接手新項(xiàng)目，改造復(fù)雜工程時(shí)，由于對(duì)代碼，對(duì)業(yè)務(wù)一開始并不是很熟悉，需要一個(gè)過渡期。但關(guān)鍵是，你要把這些問題放在心上。白天上班有很多事情干擾，上下班路上，晚上睡覺前，大腦反而會(huì)更加清醒，思路也會(huì)更加清晰。特別是白天上班時(shí)容易思維定勢(shì)，陷入一個(gè)長(zhǎng)時(shí)間的誤區(qū)，在那里調(diào)試了半天，結(jié)果大腦一片混沌。睡覺前或者上下班路上一個(gè)人時(shí)，反而能想出一些新的思路和辦法。
開放的討論。遇到問題不要不好意思，不管多簡(jiǎn)單，多低級(jí)，只要這個(gè)問題不是你google一下就能得到的結(jié)論，大膽地，認(rèn)真地和組內(nèi)同事討論。方法總比困難多！
好啦，本期內(nèi)容孫叫獸就分享到這里，我們下期見！