本文屬於技術分析和推測，本文中的數據，多是從官方數據推測得來，故無需詳細推導。
官方新聞如下：
從今天上午的情況來看，公衆購買門票的熱情極其高漲。有些羣衆很早就來到中國銀行排隊等候；官方票務網站的瀏覽量在第一小時達到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萬不知道包括哪些請求。估計只能開發商明白了。、
至於導致奧運訂票網站癱瘓的原因，官方的聲明是：
針對訂票系統因瞬間超大訪問量而造成擁堵的情況，票務中心負責人表示，由於我們對廣大公衆的訂票需求估計不足，準備工作存在缺陷，給大家申請購票造成不便。對此，我們真誠地向廣大羣衆表示道歉。
需求估計不足，性能也肯定不會做到。畢竟性能是跟着需求來做的。要不然就沒辦法做了。
如對本文有任何異議，請直接留言。