ins与apache的区别_既然nginx比apache快，为什么nginx没有取代apache？

Nginx比Apache轻量高效是肯定的,而且两者都很稳定.

netcraft统计,2016年2月份,在排名前一百万最繁忙的站点中,Apache约46%,Nginx约25%,IIS不足12%.值得注意的是,在前百万繁忙的站点中,Nginx份额接约25%并保持增长趋势,Apache和IIS均呈下降趋势.也就是说高并发的网站转向Nginx是趋势,比如国内阿里使用的Tengine就是基于Nginx二次开发的分支.

而对于大多数虚拟主机用户来说,根本谈不上高并发,因为带宽才是瓶颈,2M带宽还谈什么并发,是吧.而且Apache支持不用重载配置的.htaccess配置,在易用性上要比Nginx配置好一些.也就是Apache+PHP架构要比Nginx简单,在不追求什么并发的场景,为什么要换一套架构呢?够用能用好用就行了呗.

Nginx返回502 Bad Gateway错误不是因为Nginx的问题,而是因为后端的问题.

比如后端PHP-FPM在处理一个请求时进程崩溃了,那么Nginx就会返回502错误.

当然你可以用fastcgi_next_upstream配置让Nginx把请求转移给另一个upstream处理.

fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;

Nginx+PHP-FPM实现了动静分离,负载均衡,故障转移,在高并发场景确实要比Apache有优势.

内置PHP模块的Apache进程在处理PHP时就无法处理静态资源,而Nginx则不需要担心这个问题,因为处理PHP是PHP-FPM的事,这就是动静分离.而且Nginx支持upstream配置PHP-FPM集群实现负载均衡,这点也是Apache不擅长的.

PHP-FPM配合Nginx还可以把I/O密集操作分离出来,减少阻塞对整个PHP应用的影响.

用户下载和curl请求是典型的I/O密集型操作,因为耗时主要发生在网络I/O和磁盘I/O.

需要PHP认证的下载操作可以委托为Nginx的AIO线程池:

header("X-Accel-Redirect: $filepath");

至于curl操作,比如可以建立一个监听9001端口的名为io的PHP-FPM进程池(pool),

专门负责处理curl操作(通过Nginx分发),避免curl操作阻塞到监听9000端口的www进程池.

这时io进程池多开点进程也无所谓:

nginx.conf: 访问io.php的请求都交给监听9001的PHP-FPM进程池处理

location = /io.php {

include fastcgi_params;

fastcgi_pass 127.0.0.1:9001;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

}

php-fpm: 正常脚本由静态www池处理,阻塞脚本由动态io池处理

[www]

;名为www的进程池监听9000端口,常驻进程数量为固定4个

listen = 127.0.0.1:9000

pm = static

pm.max_children = 4

[io]

;名为io的进程池监听9001端口,进程数常驻4个,最大8个

listen = 127.0.0.1:9001

pm = dynamic

pm.max_children = 8

pm.start_servers = 4

pm.min_spare_servers = 4

pm.max_spare_servers = 4

其中I/O密集这个进程池[io]采用动态的prefork进程,比如这里是繁忙时8个,空闲时4个.

利用PHP-FPM提供的池的隔离性,分离计算密集和I/O密集操作,可以减少阻塞对整个PHP应用的影响.