原回答：
https://www.zhihu.com/question/279164955/answer/405448070
所謂的“性能”一般指的是吞吐和延遲這兩件事。他們相互關(guān)聯(lián)，但是互相的關(guān)系并不是簡單的一一對應(yīng)。
我改用一個通俗的例子來講解這個問題。
假設(shè)你去一個樂高店去買散裝樂高。首先你要排隊(duì)。等你排到隊(duì)首，跟店員說，你要小方塊紅色的10個，淺綠色花花的圓形15個，厚長條白色的3個……。店員就開始按照你說的給你去后邊倉庫拿。假設(shè)很少有兩個顧客會有完全一樣的要求，所以每次店員每次都拿的不一樣。拿一趟的時間要數(shù)分鐘。（假設(shè)店員比較傻，不會把倉庫的東西拿一部分到柜臺）
當(dāng)你提完要求后，店員可以有兩個做法：
第一種做法是：馬上去給你拿。這時對于你來講是最快的。店員去給你拿東西的時間是無法消除的，所以他馬上給你拿，對于你來說等待時間是最小的。但是這僅僅是當(dāng)你已經(jīng)排在隊(duì)首的情況。假如你在隊(duì)伍中間，你前面每個人向店員買東西，店員都要去花幾分鐘拿一趟，實(shí)際上會讓你等的更久。如果隊(duì)伍很短，或者壓根沒有人排隊(duì)，那么這樣做還是比較合適的。但如果人比較多——進(jìn)來排隊(duì)的人比店員拿東西的速度更快，這樣很快隊(duì)伍就會排出大門，而店員，要不就累死，要不就得被顧客罵死。
第二種做法是：問你和你后邊的幾個人要什么，然后一趟拿回來。這時對于你來說就會需要多等一會。畢竟店員要挨個問，需要比問你一個人要多花一點(diǎn)點(diǎn)時間。但是店員給你拿一個，和給幾個人同時拿多個樂高積木，跑腿的時間是幾乎一樣的。所以整體看來，付出了你需要多等一點(diǎn)點(diǎn)時間的代價，換來的是整個“吞吐”的提高。長時間看下來，店員可以接待完畢的顧客數(shù)量比上一種要大得多。并且，這里說的等待是說從你到了隊(duì)首到拿到東西的時間。如果從你開始排隊(duì)開始算等待時間，說不定等的時間還短點(diǎn)。
但是，店員一次行拿的東西總量畢竟還是有限的。如果比如他一次最多可以拿10人份的積木，而排隊(duì)的人每次都能進(jìn)來15個人排隊(duì)。那么即便是店員次次滿載工作，也沒法滿足顧客需要。對于顧客來講，越排在后邊的人等的時間越長。而單位時間內(nèi)，店員能夠接的顧客數(shù)量不會再增加，而是會保持穩(wěn)定。（但我相信，此時，店員的心中一定是千萬個草尼瑪飛過的）
但這還沒完。比如店員一次問10個人要的積木品種，然后去拿。但是10個人里有5個覺得已經(jīng)等太久了，不想等了，就走人（超時了）。這時店員還是得把積木拿回來。但是顧客已經(jīng)走了。于是店員的勞動就是無效的勞動。系統(tǒng)整體的利用率反而變得更低了。
相信通過這個例子你可以大概明白一個排隊(duì)系統(tǒng)里吞吐和延遲的關(guān)系，大概就是：
- 當(dāng)吞吐量小時，延遲比較低，但是延遲低到一定成都受限于網(wǎng)絡(luò)延遲、磁盤IO延遲的物理限制，無法進(jìn)一步降低；
- 通過batch/并發(fā)等方式，可以有效提高系統(tǒng)的吞吐，此時延遲會著上漲，但不會像吞吐量那樣長的那么快。
- 當(dāng)壓力超過了系統(tǒng)的某個臨界值，吞吐不升反降，并且延遲會急劇上升
然而，現(xiàn)實(shí)會更加的復(fù)雜。上面假設(shè)店員每次拿東西時的時間差不多，這已經(jīng)是非常理想的情況了。如果根據(jù)要求，店員要跑3～5個不同的倉庫，花的時間時多時少，那么系統(tǒng)的行為就會更加難以捉摸。極端情況下，店員憋不住了去大號（對，就是說你Java GC），這樣一來一段時間內(nèi)顧客的要求就完全得不到處理。
更復(fù)雜的情況是多層隊(duì)列，即不光顧客要排隊(duì)，店員去倉庫拿東西也要排隊(duì)，而倉庫的管理員去總庫拿東西還是要排隊(duì)…… 這時候拿捏系統(tǒng)的性能表現(xiàn)就很難用簡單的公式/模擬來搞定了。
所以工程上的做法都是要壓測——就是要找到系統(tǒng)的臨界值，將其作為設(shè)計的上限。生產(chǎn)環(huán)境中，絕對不要讓系統(tǒng)接近臨界值。
最后推薦一篇關(guān)于系統(tǒng)性能的文章：Thinking Clearly about Performance
其中的一副圖很有說明性。
如果看完后覺得有一點(diǎn)點(diǎn)收獲，不妨點(diǎn)個贊??～
