Ajax请求服务端性能优化

[xumingxiang]

问题背景：
"我的订单"页面，一般初次加载时,要发起3次Ajax请求，为了达到最好的用户体验效果，3次请求必须并发进行，使加载速度达到最短。但是按照已有代码进行测试，发现3次请求并没有达到并发请求，而是在一次请求结束后才开始下一次请求，这样，总的加载时间大概是每次ajax请求时间的3倍，用户体验无法达到预期。

问题定位：
在定位问题时，初步判断可能是JS并没有异步请求，导致请求在JS端堵塞，我们通过设置ajax的async属性，true代表异步请求，false代表同步请求，然后分别在服务端记录每一次的请求进入时间，当async为true和false时结果分别如下：

通过测试已经发现，当async为true时，JS是异步请求的，而async为false时，同步请求，所以将async设为true时不存在JS端排队请求的问题，排队请求其实是出在后台处理过程中。
Ajax请求后台处理排队，初步判断有可能是服务端单线程处理的问题，通过测试代码分别对每次请求进行线程和时间的记录，通过测试发现，这些请求并非是单线程处理，但是请求还是排队处理的。
排除了单线程的问题，我们推断问题应该出现在代码中，可能是一个请求的处理堵塞了其他请求的处理，或者造成了死锁。因为一个完全脱离该项目的demo是能完全实现异步请求的，不需要在服务端排队处理，所以我们就将我们项目中比demo多出来的配置项或者代码一步步加到demo中，然后通过测试demo的处理时间来快速定位问题，最后发现，是因为handler的基类中继承了IRequiresSessionState接口导致了排队处理，IRequiresSessionState只是一个标记接口，没有任何方法，他是指定目标 HTTP 处理程序需要对会话状态值具有读写访问权，因为AjaxBaseHandler基类中需要用到session，所以一开始就继承了这个接口，继承该接口意味着后台Ajax处理HttpHandler会修改session，此时IIS会自动同步序列化请求，从而导致排队处理。

解决办法：
将不需要写session的handler基类继承IReadOnlySessionState接口，他只是指定目标 HTTP 处理程序只需要具有对会话状态值的读访问权限，没有写访问权限，此时IIS不会自动同步序列化请求，因为订单ajax请求这一块基本不需要写session，所以将基类继承的接口改成IReadOnlySessionState能很好的解决这个问题，提高了性能和用户体验。