查了很多资料都说Django的runserver不适合生产环境部署，具体的原因并没有查到，目前可以得出的结论是runserver运行默认是多线程的可以支持一定量的并发，但是Django的官方并不建议这种方式。
对比下runserver和uwsgi部署的性能差异，实验环境：
1、虚拟机创建宿主机：virtualbox-2C-2G
2、在宿主机中使用docker进行部署
3、jemeter进行压测。
测试的服务直接返回结果（Hello, world. You're at the polls index.）。
测试的服务添加sleep(1)作为性能消耗假设。
测试uwsgi线程的概念和Django服务的线程之间的关系。
场景一、runserver和uwsgi分别启动1、2、3个线程对比，有多个请求来验证是否能同时为多个请求服务。
都是从第三个请求开始表现出多线程的特性？uwsgi和runserver都表现出这个特性，不知道是否和虚拟环境有关。
runserver
uwsgi
?1个线程
2个线程
3个线程
runserver的jmeter压力测试
10秒100个用户
10秒200个用户
cat /proc/线程pid/status
10秒500个用户
10秒1000个用户
?uwsgi 2C4T的情况下
在用uwsgi的时候，jmeter测试的时候keepalive的配置需要将客户端类型设置为java，才会生效，否则会有大量的error请求。这总情况在runserver中并没有出现，怀疑应该是长短连接的问题。实际测试发现如果使用长连接的话耗时会小于1秒，应该是统计的问题，后面的测试取消了keepalive的选项。
10秒100个用户
总共8个线程完全支持不了100的并发，好处是对宿主机的性能没有太大影响，保持8个线程。?
uwsgi 2C8T
?uwsgi 2C16T
?
uwsgi 2C32T
?uwsgi 2C64T
?uwsgi 4C32T
?
??uwsgi 2C64T 压测10秒200个用户
结论：uwsgi的线程数是固定的，性能和负载也是可以提前预估出来的，对服务器的冲击较小。针对生产环境也相对稳定。runserver的性能也没有想象中的那么差，从测试结果来看，针对某些简单的应用也是可以使用的。