目錄

前言

正文

看這些資料的目的

1）CPU非常非常快

2）記憶體很快了，但是相比CPU來說還是太慢了

3）磁盤性能非常非常慢

4）磁盤順序I/O比隨機讀I/O快很多

5）網路傳輸也是比較耗時的，基本都是毫秒級別

總結

最后

推薦閱讀

前言

交流群里最常聽到的一句話就是：我專案太垃圾了，面試怎么辦，說實話，我聽了也感同身受，因為我也是這么走過來的，而且，幾乎大部分人都會經歷這個程序，所以，不多說了，安排，

之所以挑性能優化這個方向，主要有幾個原因：

1）性能優化是我很感興趣的一個方向，同時在過去幾年，我在這個方向上積累了一些經驗，可以說，我之前的面試，專案上幾乎是靠性能優化一招走遍天下，因此，我覺得可以拿出來和大家分享一下，

2）性能優化非常通用，幾乎對于所有線上專案都可以適用，大家掌握了之后，立馬可以到專案中實踐起來，我想，應該不存在不需要性能優化的專案，除非你的專案只有“Hello world”，

3）性能優化大部分內容非常簡單，幾乎沒有門檻，經驗較淺的同學也很容易上手，同時性能優化也適用二八原則：掌握20%的內容，足以解決80%的問題，

4）性能優化很容易拿到結果，稍微有經驗點的同學應該知道，做需求最怕拿不到結果，性能優化就不一樣了，都是很直白的數字，1小時的任務，我優化成5分鐘，性能提升就是十來倍，簡單粗暴，

不多說了，開懟，

正文

文章的標題來源于 Jeff Dean 在谷歌的內部一次分布式系統的演講，英文標題為：Numbers Everyone Should Know，

這些數字與我們后續做性能優化息息相關，因此我將這部分內容放在第一篇，幫助大家建立基本的性能概念，

先來看 Jeff Dean 所說的數字是哪些：

注：1μs = 1000ns、1ms = 1000μs

表格第三列將耗時資料提升10億倍，換算成大家更容易看的單位，

這份資料的最初來源為 Peter Norvig 的文章：Teach Yourself Programming in Ten Years，地址：http://norvig.com/21-days.html，

伯克利的 Colin Scott 根據這份資料，通過一定的演算法，制作了一個可以根據時間的推移而變化的網站，地址為：https://colin-scott.github.io/personal_website/research/interactive_latency.html，原始碼中注釋有詳細解釋計算邏輯，例如網路帶寬是按每2年增加1倍，DRAM帶寬按每3年增加一倍，

根據 Colin Scott 的圖表來看，到2021年，網路帶寬、記憶體、SSD、磁盤，都有數量級的提升，而 CPU 相關的一二級快取變化不大，有興趣的可以自己點進去看一看，

看這些資料的目的

首先，這些資料肯定不是完全準確的，受限于眾多環境因素的影響，其實很難有所謂的準確數字，

我們看這些資料更多是了解每個操作的耗時量級，各個操作之間的數量級比率，從而對于我們作業中接觸到的一些相關知識有初步的概念，

而我將這個資料放在性能優化系列文章的開篇，主要想先傳達給各位同學幾個概念：

1）CPU非常非常快

CPU執行大部分簡單指令只需要1個時鐘周期，我用個人電腦測驗時，CPU可以睿頻到4.40GHz（見第2點的測驗圖），也就是說此時執行一個簡單指令需要的時間大約是1/4.4ns，也就是0.23ns（納秒），

這是什么概念了，舉個簡單的例子，即使是真空中傳播的光，在0.23ns內也只能走不到7厘米，

2）記憶體很快了，但是相比CPU來說還是太慢了

CPU和記憶體之間的瓶頸通常稱為馮·諾伊曼瓶頸，具體差別有多大了，我用自己的電腦做了個簡單的測驗，

我電腦是今年剛買的，硬體應該都還比較新，但是配置比較普通，僅供參考，

CPU配置是 11th Gen Intel Core i5-11400F@2.60GHz，睿頻4.40GHz，測驗結果看也確實跑到了4.40GHz了，記憶體配置是 DDR4 3200MHz，

測驗結果如下圖所示：

從上圖看，記憶體的讀取速度為41GB/s，感徑訓是挺快的，但是L1 Cache為3TB/s，一比較，相差還是很大，

如果CPU按4.40GHz來算，執行一個簡單指令需要的時間大約是0.23ns（納秒），而記憶體的延遲是88.7ns，相當于CPU去記憶體里取一個位元組，需要等待386個周期，可以看出，記憶體相較于CPU來說，確實太慢了，

這也是為什么引入了L1、L2、L3快取的原因，不過這邊我們不深入去研究這些東西，只是對CPU和記憶體的性能差距有個大概概念，

3）磁盤性能非常非常慢

這個大家估計大家都知道，具體有多慢了，我這邊在用自己的電腦做了個簡單的測驗，

我電腦剛好有兩塊硬碟，一塊256GB的SSD（固態硬碟），一塊1T的HDD（機械硬碟），

SSD測驗結果如下圖所示：

忽略佇列（Q）和執行緒（T）的影響，順序讀（SEQ）的性能為1535.67MB/s，隨機讀（RND）的性能為49.61MB/s，

對比下上面記憶體的性能41GB/s，盡管是SSD，性能還是存在數量級的差距，另一個就是隨機讀的性能相比順序讀也是存在數量級的差距，

HDD測驗結果如下圖所示：

忽略佇列（Q）和執行緒（T）的影響，順序讀（SEQ）的性能為183.49MB/s，隨機讀（RND）的性能為0.6MB/s，

對比下上面SSD的性能：順序讀1535.67比183.49，存在一個數量級的差距，隨機讀49.61比0.6，存在兩個數量級的差距，

而HDD順序讀和隨機讀的性能差距相比SSD就比較嚴重了，大概有300倍，簡直慘不忍睹，不過相信現在的服務器應該基本都是SSD了，如果發現自己公司服務器的磁盤還是HDD，那就趕緊溜吧，

4）磁盤順序I/O比隨機讀I/O快很多

這個在上面的測驗也看出來了，都是數量級上的差距，特別是在以前的HDD上，有不少技術就是利用了順序I/O性能好的特點來提升性能，典型的有：kafka順序寫訊息、Leveldb和RocksDB底層使用的LSM-Tree等，

5）網路傳輸也是比較耗時的，基本都是毫秒級別

在開始的表格中可以看到，在同資料中心一個往返，需要0.5ms，

如果是跨城市就更久了，這個相信也不難理解，畢竟信號要順著網線爬，距離越遠，當然所需時間就越久了，

下圖是上海到一些城市進行PING操作所需的時間，可以看到張家口已經需要30ms左右了，這也差不多就是北上的延遲，

這也是為什么我們在服務器的路由策略上通常會優先使用同機房優先、同中心優先的策略，

這讓我想到我之前碰到的一個問題，當時是一個新服務在測驗，資料庫基本沒資料，測驗場景也是很簡單的增刪改查，但是介面的性能就是很差，動不動就上百毫秒，

仔細看了呼叫鏈后，發現每次DB操作都需要30ms左右，看了下機房分布后，發現是應用服務器和資料庫服務器跨城市了，一個在北京一個在上海，導致會有固定30ms左右的延遲，將兩者換到同機房后，基本就是1ms了，

總結

本文著重介紹了業務開發在做性能優化需要掌握的一些核心概念，之所以放在最先介紹，是因為在我做性能優化的程序中，發現絕大多數性能問題都是由于網路I/O和磁盤I/O引起的，對這些概念心中有數后，有利于我們更快的定位出性能瓶頸，從而更快的解決問題，

有同學可能會問，下一篇文章什么時候，不會又是兩個月后吧？

答：跟大家聊下為什么更新間隔這么久，一個是確實變懶了，這個毋庸置疑，有一些其他的事情就忘了這邊，比如從幾個月前開始我堅持每天健身，當然歸根到底有很大的原因是動力的問題，

另外一個就是作業確實比較忙，現在做的專案比較有挑戰，基本都是幾十萬上百萬的QPS，幾十億的資料量，很多問題都不可同日而語，因此要做的事情很多，挑戰比較大，所以需要花比較多的時間去思考和維護，

然后，道理是這樣的，很多同學都有白嫖的習慣，這個我不反對，因為我自己也經常白嫖，但是如果你確實覺得這個系列文章對你有幫助，你希望能加快更新速度，那最好的方式是給我點反饋，一鍵三什么你懂的，

我需要有反饋才能知道文章對大家是否有幫助，如果好的反饋多了，我知道文章對大家幫助很大，自然就會更新的勤快點，通宵什么的說不定也干的出來，我狠起來我自己都怕，

最后

我是囧輝，一個堅持分享原創技術干貨的程式員，

推薦閱讀

Java 基礎高頻面試題（2021年最新版）

Java 集合框架高頻面試題（2021年最新版）

面試必問的 MySQL，你懂了嗎？

面試必問的執行緒池，你懂了嗎？