来818目前12306网站的性能问题

森林一木 · 发表于 2012-1-17 17:25:38

最近看到了很多关于12306网站的报道，从一个技术人员的角度，发表一下自己的看法。
09年在北京的时候，与朴老师一起去社保部交流公务员网站报名系统测试的时候，对这种架构就有了一定的想法，后来分析了电商及门户网站的设计模型，个人感觉12306网站的问题应该比较容易处理，如果给我们51testing来做性能的话，

下面大概分析一下，欢迎各位讨论！

从目前前端页面来看，12306的网站使用的是J2EE架构开发，具体web服务器不晓得是啥，估计Web服务器是Websphere，数据库可能是用铁道部以前老的数据库，如果是这种情况，如果我们做性能测试的话，我觉得可以从以下几个方面进行考虑
1、首先是系统架构设计，以前我接触过这样的一个架构：HTTP Server做业务请求处理，Websphere做Web服务器，调用CICS中间件，操作系统是AIX，数据库用Oracle，当然有很多个应用服务器。这种架构，各个环节设计妥善，能够支持很庞大的业务请求。从12306网站来看，如果所有用户发出的请求是先查询车次，再看余票信息，然后购买，那么可以根据IP进行负载均衡处理，分发到各个节点上，可以做CDN分发到各个节点，动态请求，真正的业务处理可以在节点完成。这样，在处理请求的时候就减轻主服务器的压力。具体数据信息，比如JS等资源文件可以压缩后传递，加快传输速度，具体业务请求由Websphere进行处理，经过中间件与数据库进行交互，从目前来看，如果数据库用的是老系统的话，应该是没有啥问题，问题可能就在中间件和websphere的处理上（以前售票点的数据库应该也是联网，速度也没现在的慢。所以，老数据库应该还不错）
2、并发处理方面，系统应该设计容纳的最大并发数量，防止用户过多产生堵塞，可以采用排队机制，避免大量用户请求涌入，这点应该首先估计一下今年通过网络订票的人数，我想业内都有成熟的估算方法，这样可以得到一个最大的并发数和访问量，测试人员在开始测试的时候就应该考虑到，另外根据订票的流程，初步分析可能引发大量并发操作的业务，本身系统已经运行了一个时期，那么根据运行日志是否可以得到关键功能点的用户访问趋势统计数据，这样在测试的时候也是个参考。所以，设计一个阀值进行排队，这样也是一个处理方法，至少能保证业务的成功。
3、用httpwatch进行查看，每个页面上的资源文件都比较大，这样是不利于数据传递的，所以，还可以优化文件的大小，减少客户端请求的数量及数据包大小从而提升下载速度，减少带宽占用。
4、针对这样的系统，是否可以将大量的数据库查询，调用数据的过程放在缓存中，与内存交互，另外订票流程也是有问题的，存在一个记录锁定的问题，这样的话，数据锁定时间过长，会导致大量票被锁定，其他用户无法进行购买（实际上并没有支付），从用户角度来说是比较好的，但他的付款时间无法控制，可能很快，也可能很慢，这样的话，就导致票信息被锁定时间太长，会造成更大量的访问了。因为成功率下降，用户尝试次数会增加，如果在付款流程设计成余额支付是否会好些。比如在他查询车次信息的时候，就自动检查他的余额信息，让他先充值再买。
总结下，从架构，业务逻辑，客户端数据几个方面，分析下来，12306网站优化的地方有很多，看了新闻说已经增加了带宽，速度上去了，我试了试，没啥变化，纯粹指望硬件来提升，很难的，也很费钱，不过他们有钱，呵呵。