今天的高考查分比去年流量来得凶猛一些，虽然事先也做了充分准备但是仍然比预计的要大，也造成了一点小小的麻烦。
去年网站访问的流量100M端口达到饱和，今年开始准备的是2×100M的端口捆绑，web节点准备的20台，25日上午9时访问流量就逼近了200M最大限制，前端的radware分发交换机的负载情况也非常不乐观，CPU利用率达到了99％以上，Ping延时达到了200ms左右，后端web节点倒是较为轻松，但是由于延时较大，连接保持花费的资源过多。
路由器的网站端口流量：

经过分析和简单实验后觉得可能是由于网络流量达到带宽饱和程度，同时可能radware处理端口捆绑的能力和效率不够，中午抓紧时间做了临时处理，直接使用GB7直连radware和交换机，访问效果有了很大改观，网站流量下午18时超过了200M达到当日最大的220M，radware的CPU利用率也降低到了60％左右，ping延时80ms左右。
晚上做日志分析的时候招生信息网的25日web日志创纪录的达到了11G，原来的日志服务器太慢了，换到了SAN上花了三个多小时终于分析完。文件数5048万、页面数265万、IP量27万、web流量373G字节。
今年查分的高峰访问基本过去，录取的高峰即将来到，但是一般低于前者，所以今年的高峰访问基本过去，但是需要总结和准备的东西也非常多。
1、做好明年流量会继续增长的准备。虽然使用了千兆端口，但是目前Radware的处理性能仍然不能满足需要，从延时和CPU利用率可以看出。解决办法要么使用多设备对分发本身做负载，要么换用更高处理性能的分发设备，同时还要研究下IPVS在多链路出口情况下的结构。
2、web节点和应用的优化。使用gz压缩减少字节流量；在大并发的时候减少会话保持的时间；提前检查日志尽量避免404等页面错误；apache的优化还需要再研究。
3、cache的利用。必须把一些不变的页面元素cache，比如css、js、image、html等，在系统前端提高处理的性能。