51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 4317|回复: 17
打印 上一主题 下一主题

[原创] 论【12306.cn】的性能测试

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2012-1-15 23:10:53 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
大家好,这段时间大家应该都很关注12306.cn这个网站的情况,尤其是在外流浪想回家的游子,想买火车票而不得的郁闷心情。这个网站的情况我就不多说,据称是耗资将近5千万,点击量更是达到号称全球TOP10。有网友说这个网站没有经过现场模拟,更没有经过性能测试。到底有没有我们不得而知,起码是没有经过完善周到的性能测试,太烂了。
      如果我们是一个负责这个网站性能测试的测试人员,我是说假如,呵呵!我们该怎么做?
      首先我们抛开身份证这个ID,或者说已有无数个身份证ID可由我们调用。下面的流程该怎么做?我先来抛砖一下,其余大家各抒己见.....
        正常功能模块:注册,登陆,查询车次,购票,付款
        性能需求:用户注册2s/个,登陆3s/次,查询车次1s/次,购票5s/次,付款4s/次
                      同时支持500W人在线,并发操作人数100W人,最高点击率5000W
                      CPU占有率不超过75%
                      为保障server的服务质量,超过人数的拒绝用户的继续登陆
         难点:假如20台server的负荷分担
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2012-1-16 11:17:29 | 只看该作者
还需要详细了解系统布署结构,比如WEB服务器部署在哪些区域,数据库的部署结构情况等等。然后根据这些进行相应的测试,这样的测试倒不是什么难点,我倒觉得12306.cn是性能需求没有搞清楚;低估系统需要承受的压力;系统的主要压力应该是在数据库上,12306.cn数据库结构设计可能存在问题
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    3#
    发表于 2012-1-16 11:53:12 | 只看该作者
    回复 2# qvbfnsc

    基本同意。不清楚部署结构前,提供的方案等等都未必是合适的。

    此外,用户规模数量目前不可知,但是可以考虑通过现有服务流量进行最大值计算
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2012-1-16 15:54:28 | 只看该作者
    我觉得并不是 12306 做的不好, 是性能方面在需求的时候没有考虑到该系统的使用范围、用户实际情况、以及异常处理等问题,我认为 12306的性能测试若没有通过测试指标,是不可能上线的,所以我猜测性能需求的“显性性能需求”肯定测试通过了, 而存在的 “隐性性能需求” 没有测试完全而已。
    换个角度看这个问题, 买票者 都在埋怨,网站崩溃、慢、等等各种原因,似乎所有的注意力全部聚集在网站的性能是否过关、服务器等硬件资源是否够用。 而忽略了一个问题就是“聪明”的国人啊,不按照常理出牌,人手一个 循环刷票插件,做性能的人应该可以理解, 这其实就是人手一台小型压力机啊! 敢问,我们需求做的再标准,统计网站使用人再准确,有没有考虑过 “开挂”的人呢? 其实我们真的应该反省一下尊守秩序是多么的重要啊..

    回到技术角度考虑, 电话购票,为什么没有瘫痪,没有崩溃呢 ? 我没设计电话购票系统,但是做过相类似的电话客服系统,思路基本相同,就是 一切信息确认后,通过一个 WEBSERVICE 接口,业务流程控制性高,交互简单,线程固定(比如说准备2W台电话接线客服,那么第20001个客户必须在队列中等待,秩序流程不易被打乱),通过客服系统我认为,瓶颈不应该是出现在后台,也就是说 应用服务器 与 数据库、文件服务器等还么有成为瓶颈, 那么最有可能的就是 网上订票的 前台 WEB 系统已经成为瓶颈, 当然这些仅仅是 没有经过详细调研的 乱猜测而已, 不具有参考价值, 重在讨论~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2012-1-16 17:49:05 | 只看该作者
    呵呵,对性能测试了解不深,系统布署结构是如何影响性能测试的?是指局部测试吗?
    另外数据库设计肯定是有问题的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2012-1-16 17:50:00 | 只看该作者
    我觉得并不是 12306 做的不好, 是性能方面在需求的时候没有考虑到该系统的使用范围、用户实际情况、以及异 ...
    Fin 发表于 2012-1-16 15:54


    不能这么说,首先是订票失败,人们才想到使用刷票插件的哦!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2012-1-17 09:34:09 | 只看该作者
    不能这么说,首先是订票失败,人们才想到使用刷票插件的哦!
    jacckljl 发表于 2012-1-16 17:50


    那这样说的话因为法律有局部漏洞,人们就可以肆意违法了?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2012-1-17 10:04:07 | 只看该作者
    本帖最后由 Fin 于 2012-1-17 10:07 编辑

    数据库设计我认为不一定有问题, 这个没有什么依据, 我前面分析到,因为电话订票系统可以很轻松的订购到票,就说明后台是可以正常处理相关业务量的, 我认为数据库肯定是公用一套数据库的,否则不好处理车票单一性的业务需求。 可以说现阶段,还没到数据库的瓶颈时,前台WEB应该首先成为瓶颈。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2012-1-17 11:22:13 | 只看该作者
    本帖最后由 云层 于 2012-1-17 11:28 编辑

    如果你这样做性能测试,那么真的很失败很失败!

    问题的关键是怎么解决长锁的问题,因为订票后要45分钟内完成支付才能出票。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2012-1-17 11:25:00 | 只看该作者
    Web压力肯定也很大,但这些应该都比较好解决;这个网站的网面不是很多完全可以都做成缓存,还可以分地域放置服务器,在一些外来工比较多的城市(北京、上海、广州、南京等)多放置几台WEB服务器,web不需要向数据库一样需要实时同步;主要的瓶颈可能还是在数据库上,多用几台数据服务器分担压力吧,但又存在数据同步问题,少用了压力又太大;我想应该在数据库设计时,将票务查询、订购票的业务分开设计成不同的数据库,还可以将一些到达湖南、湖北、四川、江西(这些外出打工人员较多的地域)的车次专门设计数据库;在业务操作时也可以加一些措施减轻压力,比如:每查询一次都需要输入一次验证码、每个身份证每隔一段时间内(可以是5分钟、30分钟、1个小时或1天)只能查询N次;
    从现在12306.cn网站来,这个网站只在查询和订购时加入了限制,网站的其他页面并没有限制,应该从侧面反映WEB压力他们是解决了,主要还是数据库的压力问题;还有觉得现在那个网站超过一定的用户数就禁止登陆这个不是很好,很多直正想订票的都被挡在外面;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2012-1-17 11:47:52 | 只看该作者
    好吧,我还是引用了一位大神写的评论,看完了再想想“你们这是自寻死路”http://blog.csdn.net/jaminwm/article/details/7183773

    本文不涉及技术,描述的是项目背景下的实施背景,在这个背景下所需的“穿针引线”“各个击破”“补窟窿”的软实力,这不是技术手段所需的金刚钻。因此,题目拟为隐喻“穿针引线”“各个击破”“补窟窿”的软实力——绣花针。特为解释,博文一篇酒后乱言,请勿吹毛求疵,不求工整对仗,只为记录心迹聊表意会             请回复的人不要乱喷,动不动说人垃圾,我一笑了之。 世上没有人是傻子,你能知道金刚钻瓷器活的歇后语,不代表别人不知道,为啥为绣花针如上已经解释。不仔细看帖子看回复的人估计也就是个稀烂的班子。


    周末,看到一堆泥腿子来CSDN上谈论铁路订票系统瘫痪的问题分析。换位思考一下,觉得真的很难,换成谁估计都无解。


    从项目本身来看。
    一、太极公司作为系统一级资质的系统集成大公司拿到这验收个项目,关系是铁定的,利润未必有多少是自己的,现在的甲方铁道部层层验收,拿项目费用是非常非常大的。这一点在我上次给国家税务总局南海数据中心做容灾项目的时候就领教过了。
    而作为乙方,项目经理没有足够的人员支配权力和外包单位否决权,领导一个副总要把WEB层包给张三,数据库设计包给李四,不是技术总监等技术人员能拍板的。

    二、如上所述,一个大项目,可支配的用于项目技术方面的配额是有限的。怎么办?只有拿出自己公司最牛B的技术大拿来设计并总包了,可惜做SI的人经验再丰富缺2点这个系统最要命的经验:1,内部系统和互联网系统的架构设计是不一样的。2,接口部分的设计没有关系和大佬打招呼,人家甲方的其他接口人员是不吊你的。

    三、接着,赶工期让手持PMP证书的一线项目经理明知进度和风险控制是这个项目的悬头三尺剑,也不顾了——老板验收了才有年终奖是王道

    四、接着,Loadrunner资深背景的工程师在一线也不顾负载压力的风险控制了,模块写完是王道——已经几天几夜没有睡觉了——谁他妈的让你测试了,分包当中没给钱,要测试就得耽误进度。

    五、当初投标技术方案中有IBM,思科,EMC,oracle众多好手给出了在许多项目中得到论证检验的架构设计,充分考虑了安全性、网银接口(查询、同步、异步)、负载均衡集群、故障切换、容灾设计、session同步、会话转移、更有甚者Oraacle把Exedata都拿去做PoC测试了。可惜乙方中标后由于种种原因都一一砍掉。厂家有良无良的工程师都爱莫能助了——老板说了,这个单子Q末没有进来,OO没有拿到,乙方又没有人压货。所以我们不能suport了,对不起。

    六、接着,写模块的程序员到了项目中期才发现,坑爹的票务综合数据有好几个重要接口在项目开始就要了,人家种种刁难不给你。最后产生了坑爹的银行接口不全、票务状态信息接口不全等设计客观原因。

    七、好不容易开了N个会议后,项目经理去一个接口的专责科室一个个去敲门,解决了一半,还有一半的专责出差的出差,培训的培训,见了的也摆谱,你的级别和我不对等,让你的老板来,碰了一鼻子灰。回来了后老板不在——年底了,集成公司都在收款,年终答谢,饭局、KTV,答谢会,谋划明年的Quota,密谋明年坐哪把交椅——都忙,缺都没有上心接口的事

    八、最后,无法规避坑爹的发生,时间和成本让你无法重构session同步和证书网银的代码,最后只有坑爹的让你延时时间到1个小时。为什么?因为代码不能动了,只有让SI的管理员在中间件上改参数了。你重改的代码即使build了也不能发布到集群节点上了,为啥?你没有权限,甲方没有审查签字,甲方在干嘛?甲方在忙着年终决算,忙着XX忙着YY。

    九、硬件扩容?分包给了别人,利润蛋糕都切完了,没有人会管你

    十、架构设计?SI没有足够的利润请淘宝、京东、携程、微博这样的有分布式架构、互联网web设计经验的外包。腾讯的马化腾也没有理由干这么个水深的场子,利润率还不如卖几个Q币来的扎实。

    十一、再外包救火?你傻啊,再外包意味着事干完了干得好不是你的功劳,还影响你的位置,干得不好够你喝一壶的。就算你的私下找到了支付宝的牛B架构师程序员出来友情出演一把,个婊子,你还得自己先垫钱给人家解决差旅,自己已经有好几个月的铁道部驻场三陪吃喝玩乐费用没有报销了,老子的白金信用卡额度也要刷爆了。还得抽空回公司一趟贴发票签字拿钱。

    十二、这个项目面对春运,面对年关,团队的兄弟们都指望着年底发多少钱呢,这个通胀压力大的年代,谁能有持久性的专业态度来两耳不闻窗外事,一心只写好负责的代码呢?因此这个时候,什么RUP,什么XP,什么敏捷,都扯淡吧,军心难易啊,没给你消极怠工算给你面子了。更何况这个项目抽调了SI公司几个事业部的人,对于SI这样的占山头气氛普遍的公司来说,没有一个牛B的政委,开发计划是无法落实的,甘特图成了摆设。日报周报成了负担。

    十三、项目到了后期了,才知道为啥人家甲方数据科的王姐不配合我,原来不是我长的丑,是我公司档了人家的财路。唉,咋办咧?项目经理开个小会,这样,人盯人吧,三陪卖身反正兄弟们不亏,想尽办法逐个击破,小张啊,我们这些兄弟就数你最懂女人,最帅了,这个事你就多担待点了。我会在刘总那儿美言几句,明年调你做行业二部副理。——诺——须知一将功成万骨枯。每天都在上演很傻很天真的事。

    十四、总算上线了,被投诉了,被落井下石了,被白搞了——结果,答应的承诺的,都没法兑现了——老板,您看,这年终奖是不是可以。。。——还好意思要钱?妈的,你们这个水平都被全国人民骂了,都上新闻联播了,老子的年终奖张总都扣了,你还好意思要。。。

    十五、悲催的加班、陌生的嘴脸。结论:又是一帮没有拿从业许可证的IT民工的责任,铁道部已经责成。。。要求。。。2012年订票系统将会重新招标。。。新的故事又开始了,刘处,去年他们中了标,今年要不给李处个面子,让山东那公司来做,赚钱轮流做嘛。“好说,好说”
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    前天 09:06
  • 签到天数: 941 天

    连续签到: 3 天

    [LV.10]测试总司令

    12#
    发表于 2012-1-17 13:20:10 | 只看该作者
    回复 11# 云层


        云层的开场白怎么那么像“伊利丹”。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    13#
    发表于 2012-1-17 17:31:24 | 只看该作者
    如果你这样做性能测试,那么真的很失败很失败!

    问题的关键是怎么解决长锁的问题,因为订票后要45分钟内 ...
    云层 发表于 2012-1-17 11:22



        业务逻辑改一下,用余额支付,可能损失了易用性,但应该能够保证效率。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2012-1-18 14:50:57 | 只看该作者
    回复 4# Fin


        说的好~灰常同意
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-6-2 16:41
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    15#
    发表于 2012-1-19 11:49:26 | 只看该作者
    回复 4# Fin
    循环刷票插件的出现是因为网站无法登录、无法正常提交订票而寻找的一条出路
    也就是说先有了性能问题,再有的插件,然后导致了性能问题的更加突出
    我觉得这样一个订票网站不是面向全国,而是分散到各个铁路局或者各个站点,所面临的压力应该会小很多
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    16#
    发表于 2012-1-19 17:33:46 | 只看该作者
    悲催的事情,技术人员不是死在技术上。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2012-1-29 13:09:45 | 只看该作者
    那篇牛人的文章不错。够诙谐够和谐。顶
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2012-1-29 14:00:09 | 只看该作者
    看完了,先是性能出问题,大家才用插件的
    这个网站数据库设计有问题,排队系统有问题,接口有问题
    挨骂是应该
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-5-2 12:50 , Processed in 0.113942 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表