nginx线程池好吗(nginx多线程还是多进程)

nginx多线程还是多进程

1、Nginx基本工作原理

NGINX以高性能的负载均衡器，缓存，和web服务器闻名。Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，当它接到一个HTTP请求时，仅仅通过查找配置文件将客户端请求映射到一个location block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。

因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。

Nginx的模块直接被编译进Nginx，因此属于静态编译方式。启动Nginx后，Nginx的模块被自动加载，不像Apache，首先将模块编译为一个so文件，然后在配置文件中指定是否进行加载。在解析配置文件时，Nginx的每个模块都有可能去处理某个请求，但是同一个处理请求只能由一个模块来完成。

nginx 进程数设置多少合适

Linux每个应用运行都会产生一个进程，那么我们就可以通过查看Nginx进程是否存在来判断它是否启动。

1、有时想知道nigix是否在正常运行，需要用linux命令查看nginx运行情况。执行命令：ps -A | grep nginx。 如果返回结果的话，说明有nginx在运行，服务已经启动。如果不怕nginx关闭的话。也可以执行：service nginx restart。 把nginx服务重启，在重启时，也可以看到具体有没有什么地方出错。

2、看端口netstat -ntlp； 看进程ps -ef|grep nginx； 看日志是否更新tail -f access.log。

3、直接查看进程id：ps -C nginx -o pid。 这种直接返回pid的方式比较适合跟其他程序结合使用，比如在shell/python脚本中执行这个命令拿到pid，让后根据pid来判断Nginx是否启动。 推荐使用这种方式。

nginx 多进程

Nginx的工作模式很简单，就是采用一个master进程和多个worker工作进程，其中master进程的作用也是很明确的就是负责管理worker进程，同时监听连接请求，当连接请求到来之后将连接放入worker进程中去处理具体的业务请求，比如说http请求。

Nginx能够处理高并发的原因在于对socket的管理方式是异步非阻塞的，使用select/poll/epoll/kqueue 来实现对大量socket描述符的管理，每个worker进程有一个主线程，而没有其他的线程这样的好处就在于不需要进行线程间的切换，这样就节省了资源。

所以总的来说：Nginx能够实现支持高并发的同时运行效率还很低的关键在于整个系统内部只有有限的几个工作进程和一个监听进程，而每个进程内部只有一个主线程，这样就不会引起很多的线程切换，从而降低了系统开销，同时每个线程内部使用异步非阻塞的方式来管理描述符这样就可以管理大量的描述符，当描述符多的时候也只是会占用较多的内存而已，而不会造成占用大量cpu时间。

以上说的就是Nginx的进程模型和事件模型，事件模型中处理的情况主要有三种，分别是网络事件，如HTTP请求等，网络事件使用异步非阻塞模式就可以很好的解决；还有信号，定时器，信号和定时器还不是很明白。

Nginx处理进程间争夺系统资源的方式：也就是进程间存在的惊群现象。

nginx 多进程还是多线程

　　Nginx会按需同时运行多个进程：一个主进程(master)和几个工作进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。Nginx主要通过“共享内存”的机制实现进程间通信。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。　　在工作方式上，Nginx分为单工作进程和多工作进程两种模式。在单工作进程模式下，除主进程外，还有一个工作进程，工作进程是单线程的；在多工作进程模式下，每个工作进程包含多个线程。Nginx默认为单工作进程模式。

nginx 线程数

sleep()这个函数会导致PHP解释器被阻塞,也就是会导致一个PHP-CGI进程被阻塞,如果Nginx后面只有一个PHP-CGI进程,那多个请求自然就得排队等待PHP-CGI处理了,阻塞的不是Nginx,而是PHP-CGI. Windows上Apache内有多个线程,一个线程处理一个请求,所以服务才不会阻塞.

nginx单线程

Python Web 程序的部署方案

综合而言, 高性能的Python web站点部署方式首推 nginx + uwsgi

apache + mod_wsgi 是简单稳定但性能一般的方式

API服务器 可以直接使用tornado或者gevent

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用 Apache 部署是一个不错的选择。较早的时候，使用 mode_python 部署python的web应用十分流行,在Django 0.96 的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的，每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义。 基本上所有的python web框架都实现了wsgi接口，用mod_wsgi 能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署python web程序，推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点：不建议用fastcgi的方式部署Python web。

前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。 当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCP connection（FastCGI进程在远端的server farm）传递给FastCGI进程。

主流的web服务器，Apache,lighttpd,nginx 都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。

fastcgi 并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署python web程序，fastcgi 都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能python web程序的部署方式了。

在1U的四核XEON服务器上，一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP 1U 服务器上，基本不用管它。

上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。

tornado

tornado 号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx 1.14 以后的版本反向代理支持长连接，配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。

gevent

gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。