Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix zh-tw/ch1 typoes #145

Closed
wants to merge 1 commit into from
Closed

Fix zh-tw/ch1 typoes #145

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions zh-tw/ch1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@

***釋出推文***

使用者可以向其粉絲髮布新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。
使用者可以向其粉絲發布新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。

***主頁時間線***

Expand Down Expand Up @@ -187,7 +187,7 @@

推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作。

然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲髮送推文。
然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲發送推文。

在推特的例子中，每個使用者粉絲數的分佈（可能按這些使用者的發推頻率來加權）是探討可伸縮性的一個關鍵負載引數，因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵，但可以採用相似的原則來考慮它的負載。

Expand Down Expand Up @@ -234,7 +234,7 @@

**排隊延遲（queueing delay）** 通常佔了高百分位點處響應時間的很大一部分。由於伺服器只能並行處理少量的事務（如受其CPU核數的限制），所以只要有少量緩慢的請求就能阻礙後續請求的處理，這種效應有時被稱為 **頭部阻塞（head-of-line blocking）** 。即使後續請求在伺服器上處理的非常迅速，由於需要等待先前請求完成，客戶端最終看到的是緩慢的總體響應時間。因為存在這種效應，測量客戶端的響應時間非常重要。

為測試系統的可伸縮性而人為產生負載時，產生負載的客戶端要獨立於響應時間不斷髮送請求。如果客戶端在傳送下一個請求之前等待先前的請求完成，這種行為會產生人為排隊的效果，使得測試時的佇列比現實情況更短，使測量結果產生偏差【23】。
為測試系統的可伸縮性而人為產生負載時，產生負載的客戶端要獨立於響應時間不斷發送請求。如果客戶端在傳送下一個請求之前等待先前的請求完成，這種行為會產生人為排隊的效果，使得測試時的佇列比現實情況更短，使測量結果產生偏差【23】。

> #### 實踐中的百分位點
>
Expand Down