波尔多红酒庄:性能之巔-優化你的程序 [復制鏈接]

2019-9-20 10:20
Newpaper 閱讀:497 評論:0 贊:0
Tag:  性能 優化

恋恋波尔多 www.luaogj.com.cn

?


outline:關注&指標&度量,基礎理論知識,工具&方法,最佳實踐,參考資料



性能之巔-優化你的程序



性能優化關注:CPU、內存、磁盤IO、網絡IO等四個方面。



性能之巔-優化你的程序



性能指標:吞吐率、響應時間、QPS/IOPS、TP99、資源使用率是我們經常關注的指標。



性能之巔-優化你的程序



時間度量:從cpu cycle到網絡IO,自上到下,時間量級越大。



性能之巔-優化你的程序



監控、分析、優化,三部曲,以終為始,循環往復。




性能之巔-優化你的程序



優化性能,需要一些系統編程知識。



性能之巔-優化你的程序



提升處理能力、減少計算量是優化的2個根本方向。



性能之巔-優化你的程序



優化大師格雷格畫的圖,吊炸天,你應該很熟悉,gregg親手實現了一些工具。



性能之巔-優化你的程序



借助工具定位性能瓶頸。gprof2dot.py可以處理多種采樣輸出數據

建議使用perf等非侵入式的profiling工具。



性能之巔-優化你的程序



perf不僅僅可以定位cpu瓶頸,還可以查看很多方面,比如缺頁,分支預測失敗,上下文切換等。



性能之巔-優化你的程序



IO瓶頸,你應該知道的知識。



性能之巔-優化你的程序



有關鎖的知識,你應該知道的。



性能之巔-優化你的程序



多線程的學問很大




性能之巔-優化你的程序



內存管理的方方面面



性能之巔-優化你的程序



最佳實踐,沒有足夠理由,你不應該違背。



性能之巔-優化你的程序



你應該懂得的。



性能之巔-優化你的程序



關于排序,你應該知道的。



性能之巔-優化你的程序


這些資料不錯,你值得擁有。

如果對你有幫助,請幫忙轉發,讓更多朋友收益。


  • 一般性原則
  • 依據數據而不是憑空猜測
  • 忌過早優化
  • 忌過度優化
  • 深入理解業務
  • 性能優化是持久戰
  • 選擇合適的衡量指標、測試用例、測試環境
  • 性能優化的層次
  • 需求階段
  • 設計階段
  • 實現階段
  • 一般性方法
  • 緩存
  • 并發
  • 惰性
  • 批量,合并
  • 更高效的實現
  • 縮小解空間
  • 性能優化與代碼質量
  • 總結

依據數據而不是憑空猜測

這是性能優化的第一原則,當我們懷疑性能有問題的時候,應該通過測試、日志、profillig來分析出哪里有問題,有的放矢,而不是憑感覺、撞運氣。一個系統有了性能問題,瓶頸有可能是CPU,有可能是內存,有可能是IO(磁盤IO,網絡IO),大方向的定位可以使用top以及stat系列來定位(vmstat,iostat,netstat...),針對單個進程,可以使用pidstat來分析。

在本文中,主要討論的是CPU相關的性能問題。按照80/20定律,絕大多數的時間都耗費在少量的代碼片段里面,找出這些代碼唯一可靠的辦法就是profile,我所知的編程語言,都有相關的profile工具,熟練使用這些profile工具是性能優化的第一步。

忌過早優化

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

我并不十分清楚Donald Knuth說出這句名言的上下文環境,但我自己是十分認同這個觀念的。在我的工作環境(以及典型的互聯網應用開發)與編程模式下,追求的是快速的迭代與試錯,過早的優化往往是無用功。而且,過早的優化很容易拍腦袋,優化的點往往不是真正的性能瓶頸。

忌過度優化

As performance is part of the specification of a program – a program that is unusably slow is not fit for purpose

性能優化的目標是追求合適的性價比。

在不同的階段,我們對系統的性能會有一定的要求,比如吞吐量要達到多少多少。如果達不到這個指標,就需要去優化。如果能滿足預期,那么就無需花費時間精力去優化,比如只有幾十個人使用的內部系統,就不用按照十萬在線的目標去優化。

而且,后面也會提到,一些優化方法是“有損”的,可能會對代碼的可讀性、可維護性有副作用。這個時候,就更不能過度優化。

深入理解業務

代碼是服務于業務的,也許是服務于最終用戶,也許是服務于其他程序員。不了解業務,很難理解系統的流程,很難找出系統設計的不足之處。后面還會提及對業務理解的重要性。

性能優化是持久戰

當核心業務方向明確之后,就應該開始關注性能問題,當項目上線之后,更應該持續的進行性能檢測與優化。

現在的互聯網產品,不再是一錘子買賣,在上線之后還需要持續的開發,用戶的涌入也會帶來性能問題。因此需要自動化的檢測性能問題,保持穩定的測試環境,持續的發現并解決性能問題,而不是被動地等到用戶的投訴。

選擇合適的衡量指標、測試用例、測試環境

正因為性能優化是一個長期的行為,所以需要固定衡量指標、測試用例、測試環境,這樣才能客觀反映性能的實際情況,也能展現出優化的效果。

衡量性能有很多指標,比如系統響應時間、系統吞吐量、系統并發量。不同的系統核心指標是不一樣的,首先要明確本系統的核心性能訴求,固定測試用例;其次也要兼顧其他指標,不能顧此失彼。

測試環境也很重要,有一次突然發現我們的QPS高了許多,但是程序壓根兒沒優化,查了半天,才發現是換了一個更牛逼的物理機做測試服務器。


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反?。[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 恋恋波尔多 )