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