iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 2
2
Software Development

30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)系列 第 2

30-02 之單機架構的性能優化方向與目標

黑色好看版 - 傳送門


接下來咱們會從最基本的開始 :

儘可能的優化單機性能

基本上不少高性能的書籍都是直接跳至分散式架構,但是如果一個開發者連單機都處理不好,我不太相信他開發出來的分散式架構是高性能的。

單機處理的好,才是高性能的前提。

本篇會分為以下幾個章節,來探討單機領域的優化方向,這個方向也就是之後文章的目錄。

  • 單機系統的優化路線 Step 1 (應用服務、資料庫服務)。
  • 單機系統的優化路線 Step 2 (快取服務、CDN 服務)。
  • 一個系統效能的評估指標。

單機系統的優化路線 Step 1 (應用服務、資料庫服務)


單機系統的最基本最基本架構應該長的如下圖 1,就是最簡單的應用服務與資料庫服務,咱們這裡先以最大眾的 web 服務為主 :

  • 應用層服務
  • 資料庫層服務

https://ithelp.ithome.com.tw/upload/images/20190917/20089358eS2O1xAAvC.png
圖 1 : 最簡單的應用架構。

單機應用層的性能優化方向

基本上單機應用層的優化目標如下 :

以最快與最少的資源來處理請求,並且可以最快的速度將結果回應給客戶,讓客戶於愉悅。

而要完成這件事情,基本上有幾個方向可以研究。

  • 以最少的資源進行運算,這裡比較白話文的來說就,用最少的 CPU 與 Memeory 來完成工作。
  • I/O 處理,大部份的 Web 應用都是讀取資料庫或啥的,這裡如果沒處理好,你的系統絕對只能做很少的事情。
  • I/O 的一些加速技術例如 stream、零拷貝、線程、連線池。

不過簡單來說就分兩種『運算』與『I/O』。

https://ithelp.ithome.com.tw/upload/images/20190917/20089358stShAbkxTf.png
圖 2 : 應用服務性能重點。

資料庫層的性能優化方向

資料庫層是的優化目標基本上如上應用層一樣:

以最快與最少的資源來處理請求,並且可以最快的速度將結果回應給客戶,讓客戶於愉悅。

基本上在性能方向會有幾個方向可以研究 :

  • 索引與表

它就是影響性能的最大變數,用的好上天堂,用不好下地獄,所以在們之後會花不少篇的文章來說明索引這個主題。

但是在資料庫世界中,事實上有幾個是會拖性能後腿,但是它又是不可少的東西,那就是 :

  • 鎖與事務

而這兩個就是要處理所謂的『一致性難題』,這問題非常的複雜,而且這也於分散式相關,這個地方如果沒搞懂,直接上分散式系統只是死路一條。

在資料庫世界中,如果沒有鎖與事務,那你的系統就不能讓用戶感到『愉悅』,因為它會錯誤百出,所以我們必須熟悉的理解它為什麼是拖後後腿,並且它為什麼又是必要的,這種才能儘可能的讓它們不要拖太多。

之後的文章我們將以『MySQL』這個資料庫服務來進行說明與研究,雖然不同的資料庫服務有些實作細節或啥的會不相同,它是他們的基本原理都差不多。

https://ithelp.ithome.com.tw/upload/images/20190917/20089358wLkjR5nXfy.png
圖 3 : 資料庫服務性能重點。

單機系統的優化路線 Step 2 (緩存服務)


然後通常上述兩個最基本的性能優化結束以下,會有另外兩個部份的優化服務會加入變成如下圖 4 :

  • Cache 服務
  • CDN 服務

https://ithelp.ithome.com.tw/upload/images/20190917/20089358qGUQklvSQL.png
圖 4 : 加上緩存服務的架構

這張圖基本上就是咱們這世界 80 % 以上的最基本的系統架構,之後文章咱們將會一個部份一個部份的來慢慢深入研究。

Cache 服務

Cache 服務,最主要用來將資料庫的一些常用查詢結果,先放在 Cache 服務中,為了能提升讀取性能。但它是個雙刃劍,用的好,性能升級強無敵,但是用的爛,用戶會不愉悅的。

這個地方基本上我們會以 redis 這種最多人在使用的 Cache 服務應用來進行深入研究。

CDN 服務

這個東西基本上是會放在用戶與應用層之間,它和上面的 Cache 服務相同,都是預先將某些東西放在 CDN 上,然後用戶在直接去 CDN 拿就好。

CDN 服務的提供者非常的多,這裡我們會簡單使用 AWS Cloudfront 來進行說明,因為我只用過它。

一個系統效能的評估指標


這個就是我們的目標

基本上可以分成兩個角度來看『用戶』與『開發者』。

  • 用戶: 用戶最基本的效能感受一定是所謂的『回應時間』,如果用戶做了某一件簡單的事情,但是他確需要等段會讓人不耐煩的時間,那基本上這個系統就是被用戶稱為『效能差』。
  • 開發者: 身為一個開發者,除了回應時間以外,咱們還會注意一個系統可以 hold 的住多少用戶與請求,假設同時間有 10 個請求進來,然後這時第 11 個請求進來就只能排隊會倒站,那這個系統就會被稱為『效能差』。

根據上述的兩個角度來看,基本上有兩種指標可以來滿足兩方想看的重點。

用戶重點-回應時間 (Response Time)

有時後也稱為延遲(Latency),概念如下。

Latency 就是你發送一個請求以後,你收到這個結果的時間 ( 越低越好 )。

實際上我們這三十天的其中一個目標就是『最少的延遲時間』。

延遲時間公式,就是下面這張圖,基本上可以包含幾個部份 (這裡先以最基本的 web db 系統來看)。

  1. client 傳送請求至 web 服務的時間。
  2. web 服務處理請求時間。
  3. web 服務發送至 db 的時間。
  4. db 處理時間。
  5. db 處理結果回傳時間。
  6. web 服務處理 db 回應的時間。
  7. web 服務回傳請求結果時間。

https://ithelp.ithome.com.tw/upload/images/20190917/20089358PvDjMSqDBa.png
圖 5 : 簡單版回應時間圖

開發者重點-吞吐量 (Throughput)

它的定義如下 :

在一段時間單位內,所能處理的資料量(單位請求或事務) (越高越好)。

基本這個指標,就代表你的系統可以 hold 多少使用量。

它有很多種單位 QPS、TPS,而你的系統用那種單位取決於是那一種服務,假設如果你是資料庫的服務,那基本上就是以 TPS(Transaction Per Second) 來當你的指標,而如果是一般的 Web 服務,那就是用 QPS (Query Per Second) 或是 HPS(Http Per Second)。

基本上這幾個的基本單位會解釋為 :

每秒鐘可以處理 n 個 Http request 或 Query 或 Transaction

基本計算公式如下 :

QPS = 併發數/平均回應時間

所以假設你的系統同一個時間內可以處理 1000 併發數,而平均回應時間為 1 秒,這就代表你系統在 1 秒內可以處理 1000 個請求。

結論與心得


本篇文章簡單的說明以單機為範圍,咱們最基本的系統藍圖如下圖 6 所示 :

https://ithelp.ithome.com.tw/upload/images/20190917/20089358YlZz8u6Eqv.png
圖 6 : 單機基本架構圖

並且也介紹了兩種性能指標 :

  • 用戶重點-回應時間 (Response Time)
  • 開發者重點-吞吐量 (Throughput)

而只要這兩個指標越好,基本上也就達成咱們所希望的 :

以最少的資源做最多的事情,這樣才叫高性系統。

而接下來的文章,咱們將要針對每一個地方,一個一個的深入進行深入的探討吧。

那們就正式的開始吧。

參考資料


上一篇
30-01 之何謂一個好的系統呢 ?
下一篇
30-03 之應用層的運算加速 - 演算法
系列文
30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)30

尚未有邦友留言

立即登入留言