本節書摘來自華章計算機《oracle資料庫性能優化方法論和最佳實踐》一書中的第1章，第1.3節，作者：柳遵梁 潘敏君 應以峰著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
吞吐量和響應時間是衡量oracle業務系統的基本名額，也是業務系統性能的終極名額。如何選擇恰當的名額單元來描述吞吐量和響應時間，并且熟練運用吞吐量和響應時間之間的關系是性能優化工作者最為重要的學習和實踐。吞吐量和響應時間的關系曲線如此重要，以至于本書幾乎所有的章節都是為了幫助大家更好地選擇恰當的吞吐量名額，以及更好地了解吞吐量和響應時間的關系曲線。oracle雖然從oracle 10gr1就開始提供time based analyze（tba）性能優化分析方法論，但顯然其并未認識到吞吐量和響應時間曲線的重要性，甚至到現在依然沒有明确指出該曲線對性能優化具有的根本性理論指導作用，這也緻使tba分析方法論一直沒有得到很好的利用。
1.3.1 吞吐量
吞吐量是一個簡單的通用概念，不僅用于oracle資料庫，而且可用在任何提供服務的人和裝置之上。關于吞吐量，筆者認為可以簡單定義為如下形式：機關時間内完成的操作單元數量。這裡的操作單元可以是任意粒度的名額，如transaction、executes、parse、logical reads、physical reads、user calls、latch gets、mutex gets等。
從性能優化的角度出發，吞吐量是一個輸入名額，響應時間展現為在該吞吐量壓力之下的輸出名額。oracle資料庫有整體的吞吐量，listener、sga、lgwr程序、cpu、i/o系統、記憶體和網絡又有其各自的吞吐量。在一個oracle業務系統中，在從客戶機釋出sql語句到傳回資料到客戶機的漫長處理流程裡，所涉及的每一個服務元件和資源（如cpu、記憶體等），其吞吐量都會有一定的限制。很顯然，隻有吞吐量的管道越來越粗，才有可能不會導緻中間阻塞，才會使業務系統響應順利流轉。
對于互動式線上交易系統（oltp）而言，其系統建設的根本目标總是被描述為在可接受的響應時間基礎之上提供盡可能高的吞吐量，這也就成為任意oltp系統性能優化的根本目标。如果一個性能優化者不了解這個oltp系統特征，而簡單強調盡可能快的響應時間，則可能會把系統優化帶入歧途。
1.3.2 響應時間
響應時間同樣是一個很簡單的通用概念。筆者将其簡單定義為：操作單元從開始到結束所消耗的時間。這裡的操作單元與吞吐量定義中的含義完全一緻。當這個操作單元完全是業務層面的最終感官響應時，就形成了端到端的響應時間，簡單而言就是從操作者發起指令到傳回響應結果所消耗的時間。
一般來說，響應時間被描述為平均響應時間，但性能優化者必須要考慮到在平均化之後所帶來的平滑可能會導緻結果不可觀察。通常，平均化會導緻以下兩個問題。
部分業務或操作的問題會被平均化平滑。
部分時間的性能問題會被平均化平滑。
尤其是時間平滑問題會帶來更多的現實挑戰，因為相當多的業務性能問題并非是長時間的持續惡化，而是僅僅在某段時間之内出現。一個優秀的性能優化者必須可以正視平均化帶來的名額觀察問題。
大量的性能優化者通常會把焦點放在響應時間上，甚至oracle的time based analyze性能優化方法論也把更多的焦點放在了響應時間之上，但筆者認為這會把性能優化帶入很大的誤區。響應時間隻是在特定吞吐量輸入壓力之下的輸出響應名額，隻是我們觀察業務系統性能的一個最終回報。尤其在oltp系統中，簡單地關注響應時間可能會帶來災難，而且有可能會采用消耗更多資源的方式來縮短響應時間，比如采用并行執行等，而這很可能是得不償失的。
對于吞吐量和響應時間的優化，不同的業務系統其側重點不同。對于oltp系統，其業務系統的基本目标為：在可接受的響應時間範圍之内吞吐量越大越好。換句話說，一筆交易在可接受的響應範圍之内應該盡可能地降低資源消耗，因為資源是有限的。對于批處理和dss系統，其業務系統的基本目标為：在有限的資源之内盡可能地縮短響應時間。換句話說，一筆交易應該盡可能地利用資源來加速業務處理。具體到性能優化，從上面可以很明确地看到，不同系統的性能優化方法和技術會有所不同。oltp業務系統的基本方式為降低機關資源消耗，快速通過并發共享區域。批處理系統的基本方式為充分利用有效資源，獨占式處理以加快響應。
1.3.3 吞吐量和響應時間關系曲線
對于性能優化者而言，吞吐量和響應時間的關系曲線圖是最為重要的曲線圖（見
圖1-1），也是tba性能優化分析方法的理論基礎。在日常生活中，我們用成語“胸有成竹”來表示做事情有把握。對于性能優化者而言，“胸中有圖”同樣也可以保證性能優化會走在正确的道路之上，而不會被混亂的表象引入歧途。
從圖1-1中可以發現以下幾點。
在一定的吞吐量範圍之内，響應時間基本保持穩定。用公式表示就是response time = service time。
在超過一定吞吐量之後，響應時間随着吞吐量的增加而增加，一直增加到響應時間不可接受為止。用公式表示為response time = service time + queue time。随着吞吐量的增加，service time将保持不變或小幅度波動，queue time則随着吞吐量的增加而不斷增加。
在超過一定的吞吐量之後，響應時間進入突變點，随着吞吐量的增加，響應時間迅速增加，并很快會導緻業務系統徹底不可用。
顯而易見，降低吞吐量、queue time和service time是縮短響應時間的主要手段。
綜上可得，一個性能優化者的根本目标就是在于延緩突變點的發生，使業務系統可以承受更多的吞吐量而保持在可接受的響應時間範圍内。比如從圖1-2所示的曲線中可以看出，從目前輸入壓力225的響應時間0.040優化為0.012左右，也許更好的描述方式為從突變點175調整為225。
1.3.4 醫院挂号視窗的吞吐量和響應時間曲線
下面以一個醫院挂号視窗的處理為例來感性描述吞吐量和響應時間的關系及優化方式。事實上，類似于醫院挂号視窗的業務在現實世界中随處可見。
假設醫院有4個挂号視窗，每個視窗的服務能力完全一樣，每個視窗每分鐘處理1個病人，每個病人的服務要求為最長等待時間不超過10分鐘，這就意味着排隊隊伍不能超過10個病人。當維持有10個病人排隊的時候，隻需要開放1個視窗就可以滿足業務需求，這個吞吐量是每分鐘1個病人，響應時間（病人從入隊到離隊的時間）是10分鐘。可以看到，在這種情況下每多開1個視窗，響應時間就會相應縮短。當有2個視窗提供服務時，每個隊伍隻有5個病人，響應時間為5分鐘；當有3個視窗提供服務時，每個視窗隻有3～4個病人，響應時間則為3～4分鐘；當有4個視窗提供服務時，每個視窗隻有2～3個病人，響應時間為2～3分鐘。這時大家可以看到，無論是響應時間還是吞吐量都在快速上升。但是，随着每分鐘排隊病人的進一步增加，吞吐量将不再增加，而響應時間則會增加，當每個隊伍增加為10個病人排隊的時候，響應時間則相應變為10分鐘，吞吐量為每分鐘4個病人。當每個隊伍的病人繼續增加的時候，響應時間将線性增加，服務品質迅速惡化，吞吐量則基本不會上升。
下面看看在病人大規模增加而視窗規模保持不變的情況下應如何保證接收的服務品質。
首先簡單分解挂号流程：
主流程：挂号職員接卡→獲知挂号科室和醫生→刷卡→選擇科室→收錢→找錢→列印憑據→将卡和憑據還給病人。
副流程：填寫病人資訊→輸入病人資訊→制卡。
由上可以看到，這個處理流程的關鍵是要讓挂号職員更加有效地利用其時間來處理資訊，也就是盡可能地使其減少無效的等待時間。
服務改善方法之一：流程改善，同步操作異步化。
很明顯，可以異步化的操作為：列印憑證和填寫病人資訊。事實上，列印憑證和填寫病人資訊也是最為耗時的操作。列印憑證是主流程的部分，至少達到總處理時間的1/3甚至以上，而填寫病人資訊則同樣費時，假設也為總處理時間的1/3，需要填寫病人資訊的病人為總病人的10%，則這兩部分異步化應該可以增加病人挂号吞吐量的35%甚至以上。
具體的異步化辦法為：列印憑證時就可以讓病人出隊，在列印憑證的同時開始處理下一個病人的挂号。填寫病人資訊時可采用類似方法處理。這樣一來，每個病人的服務時間并不會減少，甚至還會略微增加，但是每個病人的響應時間則縮短了35%以上，自然吞吐量也增加了35%以上。
服務改善方法之二：完全流程異步化以進一步增加吞吐量。
醫院可以通過增加人手，把挂号處理流程變成流水化作業。假設是完全平均分擔，即從1個人變成2個人，2個人變成4個人，則處理效率會相應地增加2倍，而響應時間則縮減為一半。為了支援更多的病人加入，可以不斷增加人手，直到增加的人手不足以抵消流水線之間的互動為止。流水線化增加了單個病人的處理時間，但極大程度地增強了視窗處理能力，使其吞吐量大幅度增加，病人挂号的響應時間也大幅度降低。當然，流水線方式也會引入額外的成本，如流水線之間的溝通和互動時間等，而且視窗會存在接收和完成之間的沖突，當人手的增加不足以抵消協調和沖突成本時，吞吐量将達到極限。
服務改善方法之三：視窗人手并行化處理。
每個視窗安排2支隊伍，而且安排2個職員提供服務，進而提供更高的吞吐量，縮短響應時間。如果需要進一步提高吞吐量，則可以在每個視窗安排更多的隊伍和更多的服務人手。顯然并行化方式會受到以下條件的限制：一是視窗之間的空間不足以安排更多的隊伍（不過，虛拟排隊可以部分解決這個問題）；二是由于單個視窗為很多隊伍提供服務，是以會導緻病人服務之間的沖突，當隊伍的增加不足以抵消視窗沖突成本的時候，吞吐量将達到極限。
1.3.5 tpcc測試的吞吐量和響應時間曲線
圖1-3～圖1-5為筆者在筆記本電腦上利用tpcc測試工具hammerora得到的oracle資料庫的吞吐量和響應時間關系曲線，從圖中可以看到，它們幾乎與理論化的曲線完全一緻，在到達突變點之後響應時間迅速增加。建議大家也進行相應的測試實踐，以增強吞吐量和響應時間曲線的感性認識，進而更加深刻地把這個關系圖映入腦海中，為你從事進階性能優化奠定良好的基礎。
1.3.6 磁盤i/o系統吞吐量和響應時間曲線
本節将簡單利用oracle orion工具對磁盤進行測試，圖1-6和圖1-7是iops和響應時間之間的關系。從圖中可以看出，随着iops的增加，單個i/o的響應時間也會随之增加。由于測試不夠充分，并沒有達到iops限制，是以從圖1-6和圖1-7可以看出以下幾點：
随着iops的增加，響應時間會同時增加，但存在相對穩定期和快速增長期。
從混合i/o響應可以看出，随着輸入壓力的加大，iops達到限制之後吞吐量不會增加反而下跌。
随着iops達到系統限制，響應時間也會快速增加。