查了很多资料都说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的性能也没有想象中的那么差，从测试结果来看，针对某些简单的应用也是可以使用的。