網站的負載能力主要還是依據每日PV的量。對於併發來講，每一個頁面請求可能有很多個HTTP請求，分別用來下載html，js，css和圖片等部分。同時，連線持續的時間也是一個重要的引數。一般來說，就這兩個引數，再加上PV的時間分佈，即一天的多少小時內產生這些PV，就可以估計網站的併發數了。計算公式如下：
PC=PV/T*C*t
其中，PC是併發數，T是觀測時間，即產生PV的時間長度，比如一天中的14個小時產生了20萬併發，則公式中T=14*60*60秒，PV=20萬。C是單個頁面請求的HTTP連線數，t是連線的持續時間，一般取一個估計使用者等待連線的時長，比如使用者在平均等待5秒發現網頁還沒開啟就不耐煩了，那麼這個t可以取5秒。不過由於網站的訪問往往有很大的不確定性，雖然我們知道平均PV，但是偶爾可能碰到訪問量井噴的時候，淘寶在搞促銷的時候就經常有這個問題，京東也一樣，我在豆瓣上沒少見到友鄰鄙視京東的伺服器承壓能力......嘛，我們在計算的時候就必須考慮這種極端情況帶來的影響，通常要在以上公式中加入一個因數，代表極端情況。那麼以上公式修改為：
PC=PV/T*C*t*f
其中f表示極端情況下PV相對於平均PV的倍數。

       需要注意的是，我們的計算僅考慮了伺服器只有一臺的情況，或者說以上計算實際上估計的是總的併發需求，並未考慮硬體上可能存在多個伺服器的情況。有些帖子裡會簡單的在上面的公式右邊再除以伺服器的個數。但本人並不贊同這種做法。因為不同伺服器往往要執行不同的應用和服務，那麼不同的伺服器被訪問的量也就不同，用這種簡單平均的估算方法並不準確，尤其是在專案較大，涉及的應用較多的時候，這種計算非常不合理。更好的做法是根據具體的需求和系統的架構來對各個伺服器進行估計。而這就涉及到技術架構的很多方面了，比如請求中有多少是靜態頁面的，多少動態頁面的，多少對資料庫進行讀寫操作的，是讀還是寫，快取怎麼安排，如果訪問量太大，單個數據庫的壓力太大，做成資料庫集群后又如何。訪問量再擴大，現有的資料架構能否跟上，伺服器硬碟的I/O效能能否跟上等，都會成為估計的問題。目前我負責的專案還處於策劃階段，所以沒有辦法做到如此細緻。但到了專案真正實施部署並測試的時候，這些應該都會成為考慮的方向。

       而頻寬的估計又跟併發有關，不僅如此，頻寬要求還跟網頁的平均大小，圖片的大小有很大的關係。技術方面，快取的方案也會大大影響頻寬的使用。在不考慮任何優化的情況下，頻寬的估算可以依據以下公式：
BW=PS*PC*8bit/byte*r/t
其中BW為頻寬大小，PS為頁面平均大小，PC為併發數，8bit/byte是單位轉換，1byte=8bit，r是因數，代表極端情況，作用跟併發估計中的f因數差不多。t指使用者能忍受的平均最大等待時間，比如20秒之內網頁沒有完全開啟，使用者就會離開，則t取20秒。同樣，這個公式估計的也是單個伺服器的頻寬需求，或者是網站的總頻寬需求。對於具體的情況，我們往往也要根據系統架構來對單個伺服器進行估計。這裡面需要考慮的因素包括網路請求中的資料平均大小，是網頁則是網頁的大小，是圖片則是圖片的大小，是Web服務介面則是通訊的訊息大小；瀏覽器端的快取使用，js，css，圖片是否放在CDN上等等。因為資訊太少，我依然無法準確估計。


      另外，以上計算的公式，我都是在網上看來的，沒有過多的去深究機理，有什麼不對的，還請高手們拍磚。