河北师范大学2016年6月13号,全校大一、大二学生选体育课，仅学校半数的学生参与选课，仅选取一门课程，教务系统即出现了严重的卡顿，学生无法登录的情况。
当天所有的手机用户，以及一切外网访问教务管理系统都会显示上图所示错误。机房以及内网可以正常打开登录页面default2，但是输入帐号密码后登录会登录失败。
对出现该情况的猜测：
1. 学校采用的网关验证上网方式
学校采用哆点的网关验证连接外网，网速百兆，在机房下载可达10M/s。但是各站点的响应速度却很慢，相比较宿舍区采用的移动4M宽带，机房最大上下行速度远远高于宿舍，但是访问站点的相应速度却有较明显的延时，可人为感知的延迟。可能分机较多，数据传输中转较多，造成了延迟。
2. 教务系统web端问题
A. VIEWSTATE问题
大多数页面，除去需要传输的选课同学的选课数据外，每次点击操作都传输了一个名为__VIEWSTATE的字段，未隐藏,该字段为一个长度为近两万个字符串，占用近20K的存储空间，而每次选课post的有用的数据，不足20个字符串。数万的用户，每次选课数次的点击，每次本应不足20个字符串的数据量，被额外增加了20K的无效数据。给网络和服务器造成了巨大的压力。
这是MS在Asp.net应用ViewState技术的特征表现。为了页面能在PostBack后依然能读取服务器控件原有的状态数据，Asp.net中使用了ViewState技术，而ViewState技术本质上是用一个默认名称为"__VIEWSTATE的Hidden类型表单域来保存和传递数据（这些数据是经过了序列化后Base64编码的字符串值，且是在方法 Page.SavePageStateToPersistenceMedium输出前保存、并由Page.LoadPageStateFromPersistenceMedium加载）。
B网站的验证设计缺陷
经过对服务器的压力测试，教务系统大约可以同时保留1800个session，每次访问登陆页面，就返回一个session，并为当前用户保留一段时间（大约120s），当用户过多，session分配达到上限时，系统登陆页面访问失败，系统奔溃。
图：一台电脑一个浏览器数次访问即可使系统崩溃
一个用户访问失败时，会再次访问，期间上一个session依然为此用户保留，会使一个用户使用了多个session，造成浪费。所以如图1所示，我们只有一台机子，一个帐号，无数次的请求登录，就会造成服务器崩溃，所以当一个学生选课时，很可能1800个session只有三四百人同时在选课就会使教务系统崩溃。
C．教务系统的各种服务端口
虽不知其用途，但存在肯定是有用，不知道占用了多少流量，暂时无法测试。
D．教务系统数据库表结构复杂
教务系统仅单张表就有7000张，数据库的维护和使用对网站的相应速度影响很大。
而选课等数据，每次用户的点击都需要从数据库中实时查询调用。数据库的维护影响巨大。
3.解决方案
A将系统改造为伪C/S架构
开发基于正方教务系统的辅助客户端,用户在选课等使用时,首次打开客户端,程序采用单session登录, 确保了服务器的每一部分资源都被切实的分配给了真实的用户,采集选课信息等数据后存储在本地,可供以后的操作使用.
简化了界面和用户的操作流程,而且程序的每次操作,只向服务器提交必要数据,减少了用户的点击所占时间,使每个用户的选课时间减少,节约了服务器资源以分配给更多用户.
B.禁用VIEWSTATE字段或压缩页面
C.选课时,以机房为主,减少机房与服务器间的分机数量
4.猜想
选课当天外网无法访问,仅限内网使用,可能是屏蔽了外网.