django多线程_Django两种启动方式(runserver和uwsgi)的区别

uWSGI 是一个(巨大的) C 应用，所以你需要一个 C 编译器(比如 gcc）和python-dev。

把它部署到 HTTP 端口 9090

现在运行 uWSGI 来启动一个会把请求传递给你的 WSGI 应用的 HTTP 服务器/路由器。

uwsgi --http :9090 --wsgi-file foobar.py

添加并发和监控

你想做的第一件事可能就是增加并发(uWSGI 默认启动一个单独的进程和一个单独的线程)。

你可以通过 --processes 选项或者 --threads (或者两个选项都使用)来增加更多的进程或者线程。

uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2

这将会产生 4 个进程(每个进程 2 个线程)，一个主进程(当你的进程死掉时会重新 spawn 一个新的)以及 HTTP 路由器(见前面)。

一个重要的任何就是监控。知道发生了什么在生产环境中是极其重要的。stats 子系统允许你用 JSON 输出 uWSGI 的内部数据：

uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191

向你的应用发送几个请求然后 telnet 到 9191 端口，你将得到大量有趣的信息。你可能想要使用 “uwsgitop” (使用pipinstall你就能得到它)，这是一个类似 top 的工具，用于监控应用实例。

一般架构：

结论：

使用execute_from_command_line方式启动django应用时, 会先加载urls, 从而会加载我们写的业务代码(views中的代码); 然后再加载中间件代码. 在应用启动完成时, 所有相关代码都已经被加载入内存。
使用get_wsgi_application方式启动django应用时, 会先加载中间件代码, 这与1中的是完全相反的。此时, 我们的业务代码仍然没有被加载, 直到第一个请求过来。如果我们在代码中, 使用了未加载的代码中的全局变量, 就会出现莫名其妙的bug

RUNSERVR

官方文档解释django自带的server默认是多线程

测试

python3 manage.py runserver 0.0.0.0:8000

django开两个接口,第一个接口sleep(20),另一个接口不做延时处理(大概耗时几毫秒)

先请求第一个接口,紧接着请求第二个接口,第二个接口返回数据,第一个接口20秒之后返回数据

证明django的server是默认多线程

python3 manage.py runserver 0.0.0.0:8000 --nothreading

重复上述步骤

#4 使用 uWSGI 服务器启动 django

#4.1 启动 uWSGI

# 在django项目目录下 Demo工程名

uwsgi --http 0.0.0.0:8000 --file Demo/wsgi.py

经过上述的步骤测试,发现在这种情况下启动django项目,uWSGI也是单线程,访问接口需要"排队"

不给uWSGI加进程,uWSGI默认是单进程单线程

#4.2 给uWSGI加进程数

uwsgi --http 0.0.0.0:8000 --file Demo/wsgi.py --processes 4 --threads 2

# processes: 进程数 # processes 和 workers 一样的效果

# threads : 每个进程开的线程数

经过测试,接口可以"同时"访问,uWSGI提供多线程

#5 总结关于django的多线程问题

Python因为GIL的存在,在一个进程中,只允许一个线程工作,导致单进程多线程无法利用多核

多进程的线程之间不存在抢GIL的情况,每个进程有一个自己的线程锁,多进程多GIL

单进程多线程的python应用可以实现并发,但是不存在并行

多进程的多处理器的python应用可能存在并行,至于并发还是并行,有操作系统决定,如果分配单处理器处理多进程,那就是并行,如果分配给多处理器那就是并行

Nginx+uWSGI可以实现python高并发