負載可以用稱為「負載引數」（load parmeters）的若干數字來描述。引數的最佳選擇取決於系統的體系結構，常見的選擇有：

• Web 伺服器的每秒請求處理次數
• 資料庫的寫入率
• 聊天室的同時活躍使用者數量
• 快取的命中率

有時平均值很重要，而有時少數的峰值更加重要。原文這裡給出了一個 Twitter 的例子來說明負載，Twitter 的兩個典型業務操作是：

• 「釋出推特」：一個使用者可以釋出一條新訊息到其所有的關注者（平均 4.6k 請求/秒，峰值 12k 請求/秒）
• 「主頁時間線」：一個使用者可以檢視其關注物件釋出的推特（平均 300k 請求/秒）

上述操作的難點在於巨大的「扇出」（fan-out）結構，即每個使用者會關注很多人，也會被很多人圈粉。Twitter 給出瞭如下圖所示的兩種處理方案：

方法 1 是將傳送的新推特插入到全域性的推特集合中，當用戶檢視時間線時，首先查詢其所有的關注物件，列出這些人的所有推特，最後以時間為序進行合併。在關係型資料庫中，可以通過如下查詢語句實現：

SELECT tweets.*, users.* FROM tweets
  JOIN users ON tweets.sender_id = users.id
  JOIN follows ON follows.followee_id = users.id
  WHERE follows.follower_id = current_user

方法 2 則是對每個使用者的時間線維護一個快取，當用戶釋出新推特時，查詢其關注者，將該推特插入到每個關注者的時間線快取中。由於已經預先計算了時間線，所以訪問時間線的效能會非常快。

Twitter 在最初的版本中使用了方法 1，但隨著主頁時間線的讀負載壓力的與日俱增，開始切換為方法 2，因為時間線瀏覽的壓力要比釋出推特高的多，所以在釋出時多完成一些事情可以加速讀效能。然而，方法 2 也存在著一定缺陷，如圖中所示，假定每名使用者平均 75 個關注者，則需要每秒約 345k 次寫入快取，而由於關注者數量的偏差，對於某些超級使用者來說，其釋出一條推特可能會導致數千萬次的寫入發生，這對寫效能的要求極大。目前 Twitter 正在考慮將兩種方法結合起來，大部分使用者釋出推特時採用方法 2，以一對多寫入時間線，而部分超級使用者則才用類似方法 1 的方法，其推特被單獨提取，當讀取時才和使用者的時間線合併。

在本例中，每個使用者關注者的分佈情況時可擴充套件性的關鍵負載引數，其決定了扇出數，在不同的應用中存在著類似的關鍵負載引數，需要根據具體情況進行判斷。