强烈推荐一个大神的人工智能的教程:http://www.captainai.net/zhanghan
一、背景:
从六月三十日到七月八日进行了一场轰轰烈烈的网考!规模:平均每天五场活动;平均每场参加活动人数:800人。当然在这期间出现许许多多的精彩小插曲,愿在此与诸君共享。
二、频繁报cookie弹出框:
由于考生都在同一时刻抽英语听力,导致网络流量太大,导致暂时网络堵塞!因此数据不能写入服务器的数据库中。艳玲姐的判断网络是否中断(原理比较cookie中是否有值,若有则弹出【表明里面的值没有写到服务器数据库中】;若无则不弹;30秒进行一次检验)!
改进:这个检测想法挺好,但如果将这个提示抛给后台让管理员去处理就更好了!
三、登录后大面积无听力:
七月一日下午活动的时候,登录大概十分钟左右大面积人抽不出听力,过了一会儿刷新页面就可以。令我们很费解,因为昨天考了一天活动也没什么问题那,今天怎么会有问题那?我们百思不得其解也猜测很多原因:局域网中Arp病毒等。
刚过了没一会儿,还是CTO厉害就猜测是文件大同时这么多人登录导致网络拥堵而大家伙儿抽不上。于是CTO让我们查听力文件的大小来验证他的猜想。果然不出其所料:今天下午播放听力的材料大小两个分别为20.4M、20.1M,而6月30号大小大概为18M左右。别看这小小2M差距当有1000人在同一时刻请求的话,这相当于网络流量增加将近2G(汗、、、)!可以简单做个计算:20M*1000=20G而 18M*1000=18G 千兆带宽由于单位换算则为每秒125M ,在这10分钟之内产生大流量使网络拥堵的概率就大大上升了。
CTO提出解决方案:
①硬件上加大带宽(现在为千兆可以换成万兆)
②根本解决方案,可通过Peer to Peer 技术来解决。
体会:什么叫厉害,能在遇到问题的时候尽快的想到出现问题的原因并能给出相应的处理办法这才叫厉害。这需要多年的经验,我们还需多多向CTO学习哈。
四、数据库管理:
七月三日上午活动,客户让加题,由于进行增题操作时误操作导致试题出现问题。因而后来修改操作耽误考试时间,使所有考生都需延长考试时间!
恕哥要求在考试期间绝对不能直接对数据库操作。应通过程序,程序可以尽可能保证数据格式以及表之间关系等没有问题。
在公司中也有专门的DBA来进行对数据库操作,开发人员等其他人无权对数据库进行操作。这极大的避免了不必要的误操作等引发问题。
下图是DBA主要工作职责:
五、总结:
经历了这些精彩小插曲,发现在现场身临其境,给人的冲击以及刺激这时解决问题,以及给人带来的印象是巨大的深远的。 一直在寻觅经验?暮然回首,经验却在灯火阑珊处。