在本地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的连接池管理可以保持数据库的长连接和复用，要改源码操作起来比较麻烦。而且都是Django 1.4时代的解决办法了，现在都Django2.2了，官方有没有提供长连接的机制支持呢？百度和查官方文档后发现配置数据库连接信息时有个可选参数叫“CONN_MAX_AGE”，默认情况下值为0，即数据库查询连接用完之后就释放掉了，新的查询又要重新建立一次连接。
将参数设置为2个小时，再次实验。启动Django后，第一次请求还是很慢，但后面的请求就加快了，问题得到了临时解决！
Todo: 至于数据库为什么要15s才响应连接，这个上班后再找DBA了解具体原因。
寄语：这次问题排查真的很艰难，尝试了各种办法，花了很多时间，终于通过抓包找到了相关的原因。讲真，通过这次问题的排查让我有增加了很多Django的知识！希望能对你有所帮助。
--------------------------------------------
20200531更新：连接mysql慢的原因
为什么mysql响应这么慢，百度一番后发现原因
mysql建立连接之前会根据连接的ip反向查找对应的主机名，这一步会涉及DNS反向解析（如果本地hosts文件没有指定就会找其他服务器查询），这个过程会消耗时间。
于是登陆数据库所在主机，通过命令"nslookup IP地址"分别查询本地IP和服务器IP，本地IP查询结果很快返回（不在一个网段找不到），服务器IP结果非常慢直到超时否没返回，这就解释了为什么前文【windows机器反应快，linux反应慢】的问题。至于为什么反向解析服务器IP这么慢，这个问题就不再继续挖下去了，应该是网管没有配置好相关的解析吧。
解决办法：禁用反向解析，找到mysql的配置文件/etc/my.cnf，增加一行配置，重启以后数据库响应速度就完美了。
[mysqld] skip-name-resolve
既然这个反向解析这么耗时，为什么还要有这个流程呢？
还记得mysql的授权命令吗：
grant all priviledges on *.* to "user"@"%" identified by "pass"
@后面的%就代表任意的主机名和ip地址，对！这个地方是可以根据主机名来授权的，如果把反向DNS解析关掉了，这里就会有问题，授权的时候就只能根据ip进行授权啦~