应用服务器数据库卡顿,请求数据间歇性严重卡顿（已解决）

背景

使用DotNet MVC架构，前端通过F12发现有两个请求(A、B)间歇性超长时间响应，通常是500ms以内能得到返回结果 ，但会时不时发生40s以上的等待响应。发生无规律，可在任何主机、时间点发生，并且比较同一时间点或同一主机均不能找到规律。A需要查询一张表，数据量大约为10W，B需要查询两张表，每张数据量约为10W。各表均在15列以内，由于每行记录有状态，无法制作索引。

暂时排除

网络：网络组的同事已经确认网络良好

硬件：在更高配置的电脑上依然有此类问题

前端代码：通过F12发现，卡顿的时候请求已经发出，处于Pending状态

框架代码：问过相关同事

服务器配置：问过相关同事

原因

该问题的来源是当时我以为我们将要同时访问SQL server和Oracle，于是在没有得到框架底层代码的情况下，仅凭猜测和小实验就对数据库连接进行了更改。最终在替换数据库连接时没有解除旧连接(以为会自己释放)，从而撑爆了连接池。

改进办法

手动释放旧的连接即可。但响应时间在线上还是有10s左右的极端情况，大部分时间是2s的响应时间，用户希望能缩短到1s以内，仍需在其他方面继续优化(因为无法直接优化连接池管理)

进展

2019-03-23

发现后台逻辑A处理得有些问题，因为框架在处理数据库时没有group by操作，故取回相应数据后使用Linq进行group by。此部分代码暂时改为直接执行带有group by的SQL，本地测试明显速度加快，但上线后只能在发生严重卡顿时降低10s左右的时间。

对于后台逻辑B，对其检验的范围做出了进一步的限定，将检索的数据从全表缩小到3000条以内，在本地执行约1~2秒，上线后仍然发生严重卡顿。

2019-03-25

发现旧系统在旧环境中的稳定性和速度都很好，询问过编写框架的同事，框架的基础代码没有改变，也请该同事帮忙设置过服务器了，但没什么用。期间发现验证密码(访问Session获取当前用户的密码，session为空则去用户表获取)的访问也出现了长达20s的相应时间，但团队没有重视，继续想办法优化A、B两个逻辑的SQL语句。

研究A、B的网络响应，发现其中A有如下两个请求，响应时间记录得不精确

大小

响应时间

4b

30s

38b

600ms

由此可以推断从服务器到客户端的网络没有问题。

2019-03-27

由于之前是在别人的框架下编写代码，当时没有提供任何的日志工具，因此也不敢随意引入诸如log4Net等。但现在已经分离，就写了个简单的日志工具来检测系统中各个方法的运行时间。没有选择使用log4Net的原因是当时项目已经很急，怕这些工具除了问题无法快速定位和解决。

经过不断地收集运行数据，终于分析到是数据库连接池管理不当导致的连接超时，同时，当初这段代码被加入了try/catch代码块，却没有很好地处理掉异常，也没有抛出异常，从而导致我们一直忽略了这个问题。