从技术角度来分析奥运订票网站的性能测试-Zee

 

本文属于技术分析和推测，本文中的数据，多是从官方数据推测得来，故无需详细推导。

 

 

官方新闻如下：

官方网站 10 月 30 日讯 今天上午 9 时， 北京奥运会 门票面向境内公众销售第二阶段准时启动。截至上午 11 时，各个销售渠道共售出门票约 9000 张，其中官方票务网站和中国银行各代售网点所售门票数量占 98% 。

从今天上午的情况来看，公众购买门票的热情极其高涨。有些群众很早就来到中国银行排队等候；官方票务网站的浏览量在第一小时达到 800 万次，每秒钟从网上提交的门票申请超过 20 万张；票务呼叫中心热线从 9 点到 10 点的呼入量超过了 200 万人次。

计算一下：

官方票务网站浏览量平均为：2200次/秒以上。

从网上提交的门票申请：200000张/秒以上。

我们先来看首页的浏览量，这里，我们可以看到

http://www.tickets.beijing2008.cn/zh-cn_static_home.html

打开这个页面加载的字节数为：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 万不知道包括哪些请求。估计只能开发商明白了。、

 

至于导致奥运订票网站瘫痪的原因，官方的声明是：

 

　针对订票系统因瞬间超大访问量而造成拥堵的情况，票务中心负责人表示，由于我们对广大公众的订票需求估计不足，准备工作存在缺陷，给大家申请购票造成不便。对此，我们真诚地向广大群众表示道歉。

 

需求估计不足，性能也肯定不会做到。毕竟性能是跟着需求来做的。要不然就没办法做了。

 

如对本文有任何异议，请直接留言。