nginx和apache的优缺点比较

  简单的说apache httpd和nginx都是web服务器,但两者适应的场景不同,也就是两者专注于解决不同的问题。apache httpd:稳定、对动态请求处理强,但同时高并发时性能较弱,耗费资源多。nginx:高并发处理能力强、擅长处理静态请求、反向代理、均衡负载。在这篇文章详细列出了apache与nginx的13个异同点,下面我们来一一分析其原理。

         1、nginx相对于apache的优点: 轻量级,同样起web 服务,比apache 占用更少的内存及资源 ,抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能,高度模块化的设计,编写模块相对简单 ,社区活跃,各种高性能模块出品迅速啊

apache 相对于nginx 的优点: rewrite ,比nginx 的rewrite 强大 ,模块超多,基本想到的都可以找到 少bug ,nginx 的bug 相对较多 超稳定。存在就是理由,一般来说,需要性能的web 服务,用nginx 。如果不需要性能只求稳定,那就apache 吧。后者的各种功能模块实现得比前者,例如ssl 的模块就比前者好,可配置项多。这里要注意一点,epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由,但并不是所有的情况下都是epoll 大获全胜的,如果本身提供静态服务的就只有寥寥几个文件,apache 的select 模型或许比epoll 更高性能。当然,这只是根据网络IO 模型的原理作的一个假设,真正的应用还是需要实测了再说的。

##对于网络IO复用模型,我自己也不懂,但是参考百度百科对epoll解释的:epoll是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率,因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合,另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。从这点可以看出,nginx采用的epoll比select在算法理论上是更高效(为什么是理论上,我举个例子,对一个O(N)与O(N^2)的算法,如果要处理的数据规模是1或是很少,这两者能体现出效率差别吗?)另外一个就是select IO模型对每个进程打开的文件描述符有限制,所以我才这个也是影响apache高并发时性能的一个因素。

        2、作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下,Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型.Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多.作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器), Last.fm 描述了成功并且美妙的使用经验.Nginx 是一个安装非常的简单 , 配置文件非常简洁(还能够支持perl语法), Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动. 你还能够不间断服务的情况下进行软件版本的升级 .

##nginx比apache支持更高的并发连接,效率更高,这与前面第一点说的有很大因素,两者网络IO模型不同,另一个就是nginx是异步处理请求,而apache是同步处理,每个进程对应一个请求。关于apache利用每个进程对应一个请求的的缺点后面还会讨论到。

        3、Nginx 配置简洁, Apache 复杂 ,Nginx 静态处理性能比 Apache 高 3倍以上 ,Apache 对 PHP 支持比较简单,Nginx 需要配合其他后端用 ,Apache 的组件比 Nginx 多 ,现在 Nginx 才是 Web 服务器的首选

##Nginx对动态处理请求弱,这个我想与它本身的实现有关吧,它需要与其他模块结合才能支持PHP等语言,而Apache则支持得较好,如果找到了底层实现的根本原因,欢迎留言指导~

        4、最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程

##两者处理请求的模型不同,直接导致了两点:a>nginx的抗并发能力强很多. b>nginx对资源需求更少,由于apache进程与请求与一一对应,在请求很大时资源需求是很大的,而且进程创建销毁代价都很大的。不过现在好像做了改进,prefork可以根据需求预创建一些进行进程,这个有点类似线程池的概念。

        5、nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式.

##这个应该与前面说的几点都有关系:nginx采用epoll IO复用模型;异步处理请求;线程与请求是一对多关系。

        6、从个人过往的使用情况来看,nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没有问题,apache重启的时候发现配置出错了,会很崩溃,改的时候都会非常小心翼翼现在看有好多集群站,前端nginx抗并发,后端apache集群,配合的也不错。

##在这点里面,我们主要关注这点:nginx+apache结合使用。既然两者各有优势,那我们就扬长避短,nginx做前端负责进行抗并发、负载均衡、做静态文件缓存,后端采用apache处理动态请求。

       7、nginx处理动态请求是鸡肋,一般动态请求要apache去做,nginx只适合静态和反向。

##nginx处理动态请求是鸡肋的原因谁能从原理方面帮解释一下?是不是由于对PHP这种语言支持不够好?对nginx适合做的就是静态请求和反向代理,反向代理是什么东东?简单的说是客户端将这nginx服务器就作为自己的目标机器,将请求发给nginx机器,至于nginx机器是将客户端需要的资源从哪里获得,客户端不在意(这就有区别与正向代理,在正向代理中是我不能访问目标机器,因为我将请求发给你代理机器,然后以你的名义去获得我需要的资源)。

        8、從我個人的經驗來看,nginx是很不錯的前端服務器,負載性能很好,在老奔上開nginx,用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好,此外apache有強大的支持網路,發展時間相對nginx更久,bug少但是apache有先天不支持多核心處理負載雞肋的缺點,建議使用nginx做前端,後端用apache。大型網站建議用nginx自代的集群功能

## 这个还是在说nginx+apache结合是一个不错的选择。

        9、Nginx优于apache的主要两点:1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡;其他的当然,Nginx可能会比apache支持更高的并发,但是根据NetCraft的统计,2011年4月的统计数据,Apache依然占有62.71%,而Nginx是7.35%,因此总得来说,Aapche依然是大部分公司的首先,因为其成熟的技术和开发社区已经也是非常不错的性能。

##apache早出现,当初人们没选择,况且小压力的网址也用apache就足够应付请求压力,所以两者市场占有率是有差距的。

        10、你对web server的需求决定你的选择。大部分情况下nginx都优于APACHE,比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端Cache、维持连接等等。在Apache+PHP(prefork)模式下,如果PHP处理慢或者前端压力很大的情况下,很容易出现Apache进程数飙升,从而拒绝服务的现象。

##apache的缺陷,抗压不行,且由于线程数飙升,资源需求量也是极大

        11、可以看一下nginx lua模块:https://github.com/chaoslaw...apache比nginx多的模块,可直接用lua实现apache是最流行的,why?大多数人懒得更新到nginx或者学新事物 ##...

        12、对于nginx,我喜欢它配置文件写的很简洁,正则配置让很多事情变得简单运行效率高,占用资源少,代理功能强大,很适合做前端响应服务器

##看了一下,nginx的配置文件确实更简洁,也容易理解

        13、Apache在处理动态有优势,Nginx并发性比较好,CPU内存占用低,如果rewrite频繁,那还是Apache吧 ##rewrite这点不是很了解,不多说

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。