what about load ?
關於訪問量，我們在談些什麼？
可以是每秒的讀寫訪問量，每秒的寫訪問，每秒的讀訪問
單獨描述讀訪問，比如乙個資料庫，只有讀訪問，那麼怎麼衡量讀的最大訪問量？
在什麼樣的配置下，有多少訪問量之後，效能才會有問題。
單獨描述每秒的寫訪問，訪問瓶頸會在記憶體達到乙個滿負荷之後，才會顯現出來。訪問的併發會加劇這種瓶頸的顯現。1000個寫請求，寫入同乙個表，或者寫入不同的表，等待的時間長短。
用什麼度量或者關鍵指標kpi,可以精確描述目前系統的健壯性？
關於 web server， 我們可以用每秒處理多少請求來衡量；
關於 database, 我們可以用 「讀寫比率」 ，「併發數」，「快取命中率」 來衡量；
第一方法是絕大多數人都會想到的，就是用二維表關聯的方法：
設計以下三個表：微博表，人物表，人物關係表。
微博表用來儲存傳送的微博；
人物關係表就是用來儲存使用者互相關注的資訊。
這裡可見的瓶頸，是：
發微博的這張表，歷史記錄會非常大。一秒4600，一天就是 4600 * 60 * 60 *24 , 差不多 4億一天。加上人物表，人物關係表的數量也巨大，10左右的使用者都在裡面。這種方法對於每秒 4600 的讀來說，都將是災難。
所以很快就產生了下面一種設計方法，而這種設計方法可能大多數人都不會碰到，因為平日的資料庫體量不會有那麼大的使用者群：
扯遠了，拉回來。如果讓你來設計這個架構，你會怎麼辦呢？
twitter 的做法是，將 大v 與普通使用者區分開來存放。大v 使用第一種方法，小v和普通使用者就採用第二種架構。
提幾個開放性的問題，以待下次回答：
1 在乙個資料庫系統中，我們如何獲得讀和寫的請求流量？
2 更深層次的問題是，怎麼知道乙個資料庫系統中，讀和寫各佔的流量比率，從而來獲得資料庫系統中，到底是讀請求佔的多，還是寫請求佔的多？讀和寫，都是請求操作。乙個系統能夠在當前配置下，支援的最大訪問量，就是他的瓶頸。
3 怎麼知道一資料庫系統或者資料應用的瓶頸，怎麼來測試？
唯讀，測試；
只寫，測試；
讀和寫，併發測試；
4 怎麼才能設計一套靈活的配置來支援線性擴充套件伺服器，滿足日益增加的訪問量
歡迎關注【有關sql】，入群討論
Python 刷訪問量
ip通過 獲取，我使用的的是https 協議的 根據自己需求選擇http或者https 協議的頁面。廢話不多說，直接上 coding utf 8 from urllib import request import requests import random import time import r...
NGINX訪問量統計
1.根據訪問ip統計uv awk access.log sort uniq c wc l 2.統計訪問url統計pv awk access.log wc l 3.查詢訪問最頻繁的url awk access.log sort uniq c sort n k 1 r more 4.查詢訪問最頻繁的ip...
linux nginx訪問量統計
nginx訪問量統計 1.根據訪問ip統計uv awk access.log sort uniq c wc l 2.統計訪問url統計pv awk access.log wc l 3.查詢訪問最頻繁的url awk access.log sort uniq c sort n k 1 r more 4...