本文属于技术分析和推测，本文中的数据，多是从官方数据推测得来，故无需详细推导。
官方新闻如下：
官方网站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万不知道包括哪些请求。估计只能开发商明白了。、
至于导致奥运订票网站瘫痪的原因，官方的声明是：
针对订票系统因瞬间超大访问量而造成拥堵的情况，票务中心负责人表示，由于我们对广大公众的订票需求估计不足，准备工作存在缺陷，给大家申请购票造成不便。对此，我们真诚地向广大群众表示道歉。
需求估计不足，性能也肯定不会做到。毕竟性能是跟着需求来做的。要不然就没办法做了。
如对本文有任何异议，请直接留言。
发表于 @ 2007年10月31日 12:07:00|评论(loading...)|编辑