我的问题是有什么优势使用nginx作为反向代理时,大部分内容是通过PHPdynamic生成的?
就我而言,nginx在将静态内容caching到caching中并一次提供多个请求方面非常有用。
这是真的 ? 或者运行nginx作为反向代理在PHP驱动的dynamic内容网站中是否还有其他优势?
如果您要求优势,则必须将其与一些替代方法进行比较:)如果使用PHP,则始终需要某个Web服务器,因为PHP本身没有。
一般而言,Nginx具有很酷的function,如:
- 你提到,在Nginx中如何实现caching有很多种方法
- 它提供了很大的灵活性,由于一大组模块,尤其是mod重写或mod lua
- 开销(内存/ CPU)相比,像Apache或宙斯networking服务器的select非常低
- 有帮助的社区回答问题
- 正在积极开发中,所以新function一直出现。 fe spdy
对nginx + php感兴趣的唯一select是在apache中使用mod_php
。 这里是主要的区别
- 几乎所有的PHP应用程序假设他们在Apache中运行,configuration语法将始终以Apache语法提供。
- 静态和脚本页面可以在apache中随意混合; 在nginx中,只能从请求本身区分静态文件和dynamic内容。 由于这个原因,configuration稍微复杂一点。 既然你不会提供静态内容,这可能不会是一个问题。
- nginx没有对apache
mod_php
等价处理,它必须向脚本解释器委托一个请求; 这是php-cli -b
或uwsgi --plugin php
。 nginx可以不启动进程; 你需要自行整理。
- nginx是asynchronous的,并且可以轻松处理高stream量和缓慢的连接,而无需额外的努力; 只要php应用程序是快速的,你几乎可以免费处理更多的stream量。 在我的组织中,即使php-cli进程的线程数较less ,我们也会在丢弃apache时遇到响应性不佳的问题。
- 如果PHP工作进程崩溃(比如说,当你尝试附加到一个多GB的日志文件),它可能无法提供解释为什么通过FastCGI; 普通的CGI没有这个问题,但是在nginx端需要一个非常不同的configuration(一个可以启动cgi进程的二级http服务器,比如lighttpd)。
我认为这篇文章可以很好地解释优势: http : //www.aosabook.org/en/nginx.html特别是对于一个缓慢的客户端案例。