本文屬於技術分析和推測，本文中的資料，多是從官方資料推測得來，故無需詳細推導。 官方新聞如下： 官方網站10月30日訊今天上午9時，北京奧運會門票面向境內公眾銷售第二階段準時啟動。截至上午11時，各個銷售渠道共售出門票約9000張，其中官方票務網站和中國銀行各代售網點所售門票數量佔98%。 從今天上午的情況來看，公眾購買門票的熱情極其高漲。有些群眾很早就來到中國銀行排隊等候；官方票務網站的瀏覽量在第一小時達到800萬次，每秒鐘從網上提交的門票申請超過20萬張；票務呼叫中心熱線從9點到10點的呼入量超過了200萬人次。 計算一下： 官方票務網站瀏覽量平均為：2200次/秒以上。 從網上提交的門票申請：200000張/秒以上。 我們先來看首頁的瀏覽量，這裡，我們可以看到 開啟這個頁面載入的位元組數為：170.216KB。 2200次/秒，也即：374475.2KB/s，約為365.6984375M。 也就是說這個站點每秒鐘處理瀏覽產生的流量就大概是366M。 而從開啟首頁，一直到確認訂票如果不重複操作的話，應該是10步。在這之前產生的流量要更大。 我們可以這樣來理解，一秒鐘有2200個使用者開啟首頁。這個是併發的使用者數。按比較密集的概率來計劃，大概有15000－22000個使用者在不同的位置開啟這一連結。這一比例應該比較高了。 我用22000個/秒使用者來計算，如果用效能測試工具來做效能測試，按每臺機器1G記憶體來計算，其他配置均不會成為瓶頸，如果一個虛擬使用者用600K記憶體，每臺機器拿400M內在來執行使用者，也需要近40臺機器來實現壓力。如果指令碼比較複雜 注：每臺機器跑600使用者，這是在效能測試中，我覺得比較高的使用率了。

每個虛擬使用者佔用的記憶體數	需要的機器數
600K	37臺
1024K	55臺

以上只是從完全沒有時間間隔的方式來執行迭代的方式來計算的。 而以上分析只是停留在瀏覽首頁的階段。 如果再加上其他的訂票步驟，估計資料量會更大，需要的機器更多。 我用loadrunner 8.1加10個使用者，大略的跑了一下首頁，看到結果中。 network time的時間比較長，這是在情理之中的，畢竟，我這裡的頻寬也不是很大，還要經過一些路由。 server time比較短，平均在0.048秒，標準方差為0.02（這個結果是我跑了三次得到的平均值）。 當然，這時肯定也有其他人上線來瀏覽，而我只是從我這個客戶端來判斷的。其他的客戶要看他們的網路質量了。 可見，在正常情況下，奧運網站的效能還是挺好的。 另外，每秒鐘從網上提交的門票申請超過20萬張，這些資料顯然沒有成功處理完。因為前面說截至上午11時，各個銷售渠道共售出門票約9000張。這個網站採用的策略是：先到先得。也就是大家一塊搶。申請肯定會很多。但是，售出的只有9000張。可見很多資料還沒能處理就癱瘓了。這裡的20萬不知道包括哪些請求。估計只能開發商明白了。、 至於導致奧運訂票網站癱瘓的原因，官方的宣告是： 　針對訂票系統因瞬間超大訪問量而造成擁堵的情況，票務中心負責人表示，由於我們對廣大公眾的訂票需求估計不足，準備工作存在缺陷，給大家申請購票造成不便。對此，我們真誠地向廣大群眾表示道歉。 需求估計不足，效能也肯定不會做到。畢竟效能是跟著需求來做的。要不然就沒辦法做了。 如對本文有任何異議，請直接留言。