IIS、asp.net 中TTFB诡异的500ms时间

摘要

最近一个H5的app做优化。我写了个转发接口。每次请求都会慢300到500ms，匪夷所思

最近一个H5的app做优化。我写了个转发接口。每次请求都会慢300到500ms，匪夷所思

问题发现

最近H5做了重构。
由于接口的安全原因 不得不做了一个转发接口。
转发接口接受来自h5页面的http请求，解析参数，处理敏感数据，然后调用后端的api完成接口逻辑。

最近发现一个奇怪的问题。
每次打开页面 TTFB的速度莫名超过300ms。排查日志发现整个转发接口处理时间不超过20ms，而后端的api也不超过15ms，那么这300ms
但是iis日志中显示此次请求确实话费了320ms 那么这300ms到期哪去了？

时间去哪了

转发接口中所有io操作全部用的异步，比如调用后端api的http，文件的io，甚至从http上下文中读取json参数是也用的异步。如此说来着300ms 确实不知道哪里来的。而且多次调试发现处理时间确实也就20ms。

Session是罪魁祸首

最后各种查询得知

asp.net保证同时只处理同一个sessionid的一条请求

也就是说 用了session之后 无形中等于加了一把锁。

客户端的多个请求，哪怕是同时间发出的并发请求，也会被一条一条执行，一个执行完才会执行另一个。等于一个队列。难怪每次打开页面 最后一个请求的时间总是等于前面的时间之和。

解决

把程序中所有依赖session的实现全部去掉，改用redis或者memcache缓存解决,用户授权使用jwt等方式，不依赖session

最后来个图