IIS、asp.net 中TTFB诡异的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

最后来个图

updatedupdated2024-10-152024-10-15