1.用Django写一个简单的接口（前期不会涉及数据库，我们只看http连接）。
2.用Locust对接口进行测试。
因为运行locust并模拟大量用户， 会对cpu造成极大地负担，实测发现模拟1200个用户， 将i7 cpu 一个核占满了。准备两台电脑，一台电脑运行locust, 一台电脑运行Django程序，django用的是开发服务器，也就是最基本的python manage.py runserver。 先用最简陋的方式。
我在一台i5低压版， 8g内存的笔记本上启动了locust, 发现操作系统文件描述符数量设置过小。
| hp/WARNING/locust.main: System open file limit '1024' is below minimum setting '10000'. It's not high enough for load testing, and the OS didn't allow locust to increase it by itself. See https://github.com/locustio/locust/wiki/Installation#increasing-maximum-number-of-open-files-limit for more info. |
照着这个提示，找到一篇帖子How to Increase Number of Open Files Limit in Linux。
解决完这个问题之后， 可以在服务器上启动locust, 在开发电脑上访问locust页面 服务器ip:8089，r如果跨机器访问不了，可能需要检查服务器防火墙是否允许了8089端口，sudo ufw status；如果没有8089端口，需要运行sudo ufw allow 8089 放行。另外，django程序的设置项allow_host列表追加*号。
模拟了1000个用户
使用这条命令分别查看两台电脑上django和locust的链接情况。
netstat -anpt | grep -E ‘Foreign Address|python’ |wc -l
都是1000个链接。
流量情况倒是还好，只是连接比较多。
当我增加用户到一万，过了一分钟，开始出现大量失败。
开始找原因，我先把运行django服务的主机最大文件打开数量调整到了6万， 我是通过桌面运行终端调整的， 遇到了bug,参考下面的解决方案。 （这个bug用ssh登录主机调整是不会遇到的）
如果通过桌面打开终端的方式而不是ssh登录 修改最大打开文件数失败，这是从ubuntu16就有的bug。
调整完之后，我又模拟1万个用户请求接口，竟然没有报错了， 原来ulimit -Sn是1024。
速度不稳定，没有很大的改善，rps 在150~500之间浮动， 可能因为可打开文件数量增加了，所以没有报错了。
我用这个命令查看了一下django进程打开的established文件描述符数量。
| lsof -p 11209 |grep ESTABLISHED |wc -l |
正好是一万个。
此时locust主机是单核满载状态。locust 实际是启动了10个线程， 一般500个用户，就会启动十个线程。为什么每个线程都有pid，看下面的解释。
此时django主机状态
不要被上面的图误导，多连接不会启动那么多进程,其实是多线程， 那为什么这些线程都有不同的pid呢？？？
这里我要说一个概念：
进程的pid等于tgid, 线程觉得自己的tid等于pid（这一点，线程文件夹下的status文件可以证明）, 线程的文件夹路径是/proc/< pid >/< task >/ < tid>或者是/proc/ < tid> ，线程的文件夹里面的内容绝大部分和进程文件夹里面是一模一样的， 进程和线程文件夹下都有一个status文件， 可以strings status 看一下，就懂了。
htop有一个快捷键H可以切换查看的模式。
这是django 打开的所有文件（这里推荐一下htop工具）。
附加：
这个是1000个用户压测的数据。
响应时间很长， rps抖动幅度很大。
后面我降低到了500个用户的数据。
响应时间一下就降低了， rps没那么颠簸了。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
