记一次Django响应超慢的解决过程
在本地windows机器开发的Django项目运行正常，放到服务器上后响应超慢，花了一整个工作日没找到原因（非常绝望），又花了一整个周末才找到原因和临时解决办法，如果你的项目超慢可以参考一下解决思路。
排查过程：
1.怀疑是Python环境问题，到服务器上各种虚拟环境版本进行尝试，无果。
2.因为用了mysql数据库，开始用pymysql包连接改动了一些参数，担心是驱动问题导致数据库查的慢，更换mysqlclient包后，响应依旧慢。
3.担心是有什么报错导致慢，于是艰难地开启了debug模式（由于用了pymysql所以开启debug模式也会有个报错），开启之后Django反应慢但没有任何报错，绝望~
4.都说用uwsgi中间件部署Django能加快响应速度，尝试之，没用。
5.作为运维人员的思路来了-整个链路监控吧，看看哪个环节慢了。在网上找到了django性能监控工具django-silk，装上之后发现只能看到请求耗时、sql查询耗时，sql查询耗时就几ms，也不慢啊，哭死！
6.是不是模板渲染或者代码有问题导致慢呢？
views.py中新建一个方法，不做任何处理，直接返回一个字符串，依旧慢!
7.从客户端发出请求到views.py处理计算这个过程很慢？
views.py的处理函数中增加print('test')，在浏览器中刷新网页后，查看Django输出，请求后要15s才能看到打印test。
8.客户端到服务器网络慢？
服务器上新建一个空白的Django项目，运行在相同的端口上，反应正常，网络没问题。
9.从Django接受到请求到views.py进行逻辑处理中间这个过程很慢！中间经过了django中间件middleware的处理，中间件导致的慢？
依次注释掉能注释的中间件，然后刷请求看浏览器发出请求到Django输出test的延时。
发现注释掉一个自定义的中间件后，Django很快就能输出test（看到了希望）。但是正常业务处理方法响应依旧慢。
10.自定义中间做了什么，怎么会耗费这么长时间？
查看中间件代码，发现每次请求进来Django进来以后，都要查询数据库，判断当前的url路径是否需要进行认证。
但这也是一次简单的数据库查询而已啊，为什么会这么慢，而且前面django-silk中也显示数据库查询响应很快？
有一点可以肯定的是Django查数据库这个动作耗费了大量的时间！
11.既然查询数据库这个过程慢，那抓个到数据库的包看一下？
一顿操作后发现，当接收到请求后服务器会给数据库发一点数据，然后过了10多s后又发了一堆数据，等这一堆数据打传输完后浏览器上网页就返回了，这肯定跟响应慢有联系！深挖！
linux上抓包保存到文件，下载到windows上用wireshark分析发现：当Django收到用户请求后，会主动与数据库主机进行tcp连接，三次握手很快就成功了，然后等待了15s才收到MySQL的greet信息，才进行后续的sql查询。这说明服务器很快就与数据库主机建立了连接，但mysql应用等了15s才响应。此处不理解的，可以详细看一下MySQL协议。
12.由于公司的DB是由DBA负责的，而且现在也是周末，所以暂时没办法继续深挖DB原因。接下来怎么办呢，怎么解决Django响应慢的问题？
在服务器上继续抓包，想对比一下主机上其他应用查询MySQL有什么差异，发现其他应用连接MySQL时一样会有5s的延时。在分析包的过程中发现别的应用会发送ping这样的请求，咦，这不是心跳包吗？别的应用是不是有会话保持啥的？所以没看出来响应慢？
13.给Django也设置一下数据库长连接会话保持试一下？
百度上关于这块的文章都比较老了，都是通过sqlalchemy的连接池管理可以保持数据库的长连接和复用，要改源码操作起来比较麻烦。而且都是Django1.4时代的解决办法了，现在都Django2.2了，官方有没有提供长连接的机制支持呢？百度和查官方文档后发现配置数据库连接信息时有个可选参数叫“CONN_MAX_AGE”，默认情况下值为0，即数据库查询连接用完之后就释放掉了，新的查询又要重新建立一次连接。
将参数设置为2个小时，再次实验。启动Django后，第一次请求还是很慢，但后面的请求就加快了，问题得到了临时解决！
Todo:至于数据库为什么要15s才响应连接，这个上班后再找DBA了解具体原因。
寄语：这次问题排查真的很艰难，尝试了各种办法，花了很多时间，终于通过抓包找到了相关的原因。讲真，通过这次问题的排查让我有增加了很多Django的知识！希望能对你有所帮助。
20200531更新：连接mysql慢的原因
为什么mysql响应这么慢，百度一番后发现原因
mysql建立连接之前会根据连接的ip反向查找对应的主机名，这一步会涉及DNS反向解析（如果本地hosts文件没有指定就会找其他服务器查询），这个过程会消耗时间。
于是登陆数据库所在主机，通过命令"nslookupIP地址"分别查询本地IP和服务器IP，本地IP查询结果很快返回（不在一个网段找不到），服务器IP结果非常慢直到超时否没返回，这就解释了为什么前文【windows机器反应快，linux反应慢】的问题。至于为什么反向解析服务器IP这么慢，这个问题就不再继续挖下去了，应该是网管没有配置好相关的解析吧。
解决办法：禁用反向解析，找到mysql的配置文件/etc/my.cnf，增加一行配置，重启以后数据库响应速度就完美了。
[mysqld] skip-name-resolve
既然这个反向解析这么耗时，为什么还要有这个流程呢？
还记得mysql的授权命令吗：
grantallpriviledgeson*.*to"user"@"%"identifiedby"pass"
@后面的%就代表任意的主机名和ip地址，对！这个地方是可以根据主机名来授权的，如果把反向DNS解析关掉了，这里就会有问题，授权的时候就只能根据ip进行授权啦~
到此这篇关于记一次Django响应超慢的解决过程的文章就介绍到这了,更多相关Django响应超慢内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！