nginx和apache的一些比较
1.两者所用的驱动模式不同。
nginx使用的是epoll的非阻塞模式事件驱动。
apache使用的是select的阻塞模式事件驱动。
2.fastcgi和cgi的区别
当用户请求web服务的时候,web会根据不同的需求将请求发送给不同个cgi来处理。
cgi模式,就是每次有请求的时候都fork一个新的进程来处理这个请求,处理完成后再关闭这个进程。
fastcgi模式,就是在服务器启动的时候根据配置文件建立几个cgi接口进程长驻在内存当中,当有请求连接的时候,cgi被激活来处理请求连接,处理完毕后cgi进程也不会关闭,会再次等待下次的请求连接。
因为进程的创建和关闭需要占用很大的内存和cpu资源,所以,相比较而言,处理多请求的情况下fastcgi模式的优点会不言而喻。
3.两者的支持模块
Apache支持的模块很多,而且也比较稳定。而nginx由于出现的比较晚,所以在这方面可能比不上Apache。
nginx本身就是一个反向代理服务器,而且支持7层负载均衡。
Apache的rewrit功能比nginx强大许多。
nginx是多线程的,而Apache是多进程的。
nginx处理动态页面很鸡肋,一般只用与处理静态页面和反向代理。
Apache由于支持的模块比较多,可以支持比较多的动态页面。而且性能比较稳定。
如果需要性能,就使用nbinx;如果需要稳定,就使用Apache。
以下复制于网络
不断有人跟我说Nginx比Apache好、比Apache快之类。Nginx更主要是作为反向代理,而非WEB服务器使用。我翻译过一本关于反向代理的技术书籍,同时精通Apache API开发,对Nginx和Apache的工作原理都略有了解,粗谈一下看法。
不管是Nginx还是Squid这种反向代理,其网络模式都是事件驱动。事件驱动其实是很老的技术,早期的select、poll都是如此。后来基于内核通知的更高级事件机制出现,如libevent里的epoll,使事件驱动性能得以提高。事件驱动的本质还是IO事件,应用程序在多个IO句柄间快速切换,实现所谓的异步IO。事件驱动服务器,最适合做的就是这种IO密集型工作,如反向代理,它在客户端与WEB服务器之间起一个数据中转作用,纯粹是IO操作,自身并不涉及到复杂计算。反向代理用事件驱动来做,显然更好,一个工作进程就可以run了,没有进程、线程管理的开销,CPU、内存消耗都小。所以Nginx、Squid都是这样做的。当然,Nginx也可以是多进程 + 事件驱动的模式,几个进程跑libevent,不需要Apache那样动辄数百的进程数。Nginx处理静态文件效果也很好,那是因为静态文件本身也是磁盘IO操作,处理过程一样。至于说多少万的并发连接,这个毫无意义。我随手写个网络程序都能处理几万的并发,但如果大部分客户端阻塞在那里,就没什么价值。
再看看Apache或者Resin这类应用服务器,之所以称他们为应用服务器,是因为他们真的要跑具体的业务应用,如科学计算、图形图像、数据库读写等。它们很可能是CPU密集型的服务,事件驱动并不合适。例如一个计算耗时2秒,那么这2秒就是完全阻塞的,什么event都没用。想想Mysql如果改成事件驱动会怎么样,一个大型的join或sort就会阻塞住所有客户端。这个时候多进程或线程就体现出优势,每个进程各干各的事,互不阻塞和干扰。当然,现代CPU越来越快,单个计算阻塞的时间可能很小,但只要有阻塞,事件编程就毫无优势。所以进程、线程这类技术,并不会消失,而是与事件机制相辅相成,长期存在。
总结之,事件驱动适合于IO密集型服务,多进程或线程适合于CPU密集型服务,它们各有各的优势,并不存在谁取代谁的倾向。再盲目的言之Nginx可以取代Apache的,该好好反思了。
来源 风河博客 http://www.nsbeta.info/archives/136
以下为来自hostloc论坛会员“Kokgog”的评论:
这篇文章论据大部分是对的,论点和结论在卖萌
webserver本身就是I/O密集型操作,CPU密集型的东西谁会扔给webserver做? 发展到现在, webserver的定位基本已经等同于一个实时性高的同步队列了,
unix本身的哲学就是分拆任务,放到webserver上,就是转发数据给fcgi服务器, fcgi端处理数据再call数据库服务器, 照这篇文章的论点和结论,还用什么php和数据库, 直接apache层写C模块处理请求和文本存储算了
很多大站或者企业站坚守apache的唯一原因是系统重,不方便迁移,都还在用2.4内核,用nginx/lighttpd这些异步webserver发挥不出多大作用,并不是因为apache有多先进, apache是伟大的,但是它的理念和实现放到现在就是滞后的。
所谓的lnamp里面的apache做的任务,也就等同于fcgi server,并不代表它拿来做webserver
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。