今天完成的事情：

首先是压测，对远程的服务器进行了压力测试，极限并发大约是每秒30~40，主要问题在于首页：

20并发，可以看见事务处理的非常快，查询和更新操作基本上花不了多少时间：

35并发，访问主页的时候开始大幅度降速，最后的一个线程跑的很慢

37并发：差不多是极限了，最后两个线程卡了半天，不过还是没有出现error

40并发：开始出现崩溃的线程，最后四个线程基本上GG

发现报告，发现大部分时间都是卡在首页的初次加载和返回视图上。这是因为首页有大量的图片，而且四个优秀学员的信息我是动态加载的（而且这四个学员是从数据库随机抽取的四个，每次加载都不一样），特别是头像图片的路径也是动态数据，nginx（我做了动静分离）每次都要去它的目录下面找...所以会导致这种现象发生。听说40并发算是很low了，这很有可能和我没有做缓存有关，明天开始尝试加缓存，再次进行压测。

早上的学习是有关json对象的，关于拦截器，我昨天遇到了一个问题。因为我用户登录的验证方式是绑定session而且同一时间只能单例登录，也就是说一个登录了就会把之前登录的那些都挤下去，之前线程的请求都被拦截器烂了下来，变成了无效请求。但是，这里有一个隐患，就是之前的请求如果是PUT或者是DELETE的，forword的时候不会清空响应头，从而转向登录的jsp视图时会报错，说是不支持put和delete，产生大量垃圾日志。对于这个问题我非常苦恼，只能采取这样子的处理方式：

通过判断方法体的方法来做分支判断...但是我感觉这种处理方式很不恰当，通过求助我在职工作的朋友，他告诉我可以用自定义aop环绕通知+自定义标签的方式来代替拦截器，直接分支判断返回json对象即可。我恍然大悟，然后去了解了下前端路由和后端路由的概念，发现他说的的确很有道理，不但打日志方便多了，而且连带异常处理一起做了。

这是我现在的异常处理方法：在预料会产生某些异常的地方自定义异常，然后捕获，重抛自定义异常，然后在spring的异常处理器下做统一的分类处理。这个方法其实不是很好，返回的信息也很有限，朋友告诉我可以直接返回状态码+数据的json对象即可。

比如：

比如，这里的StudentException我可以自定义状态码为200,XSSExcepton状态码是201，然后也不需要异常处理器，直接在相应的方法体里面返回json对象即可（正常的状态码比如返回0，也是一样的返回json对象）。其实这个思想是一样的，通过归类来做分支判断，分别处理，只不过json对象的方式将设计权重部分前移给前端，由他们配置路由规则来跳转，这样子更加灵活，后端出错误的概率也更小。

因为前面的任务没有要求怎么用json，而且也没有前端配合，目前我们主要的还是得用jsp。因为jsp是面向路径的，跳转还是得靠后端路由规则，所以整个代码重构并不简单。明天可以尝试一下json数据的序列化返回，然后用postman jmeter测一下，看看结果如何。

PS：听说懒加载生成的是代理对象，序列化方法还不一样，可以仔细学习下

明天计划的事情：继续任务六，尝试加缓存。

遇到的问题：拦截器的一些小问题

收获：了解了很多新的思想，学会压测