nginx+php的编译

apache一般是把php当做自己的一个模块来启动的. 而nginx则是把http请求变量(如get,user_agent等)转发给 php进程,即php独立进程,与nginx进行通信. 称为 fastcgi运行方式. 因此,为apache所编译的php,是不能用于nginx的.

注意: 我们编译的PHP 要有如下功能: 连接mysql, gd, ttf, 以fpm(fascgi)方式运行 ./configure --prefix=/usr/local/fastphp –with-mysql=mysqlnd –enable-mysqlnd –with-gd –enable-gd-native-ttf –enable-gd-jis-conv –enable-fpm 编译完毕后:

nginx+php的配置比较简单,核心就一句话---- 把请求的信息转发给9000端口的PHP进程, 让PHP进程处理 指定目录下的PHP文件.

如下例子:

location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

1:碰到php文件, 2: 把根目录定位到 html, 3: 把请求上下文转交给9000端口PHP进程, 4: 并告诉PHP进程,当前的脚本是 $documen{t}_{r}oot$fastcgi_scriptname (注:PHP会去找这个脚本并处理,所以脚本的位置要指对) 网页内容的压缩编码与传输速度优化

我们观察news.163.com的头信息

请求:

Accept-Encoding:gzip,deflate,sdch

响应:

Content-Encoding:`gzip` Content-Length:`36093`

再把页面另存下来,观察,约10W字节,实际传输的36093字节 原因-------就在于gzip压缩上.

原理: 浏览器—请求----> 声明可以接受 gzip压缩 或 deflate压缩 或compress 或 sdch压缩 从http协议的角度看–请求头 声明 acceopt-encoding: gzip deflate sdch (是指压缩算法,其中sdch是google倡导的一种压缩方式,目前支持的服务器尚不多) 服务器–>回应—把内容用gzip方式压缩---->发给浏览器 浏览<-----解码gzip-----接收gzip压缩内容----

推算一下节省的带宽:

假设 news.163.com PV 2亿 2*10^8 * 9*10^4 字节 == 2*10^8 * 9 * 10^4 * 10^-9 = 12*K*G = 18T

节省的带宽是非常惊人的

gzip配置的常用参数

gzip onoff;gzip_buffers 32 4K| 16 8K#缓冲(压缩在内存中缓冲几块? 每块多大?)gzip_comp_level [1-9]#推荐6 压缩级别(级别越高,压的越小,越浪费CPU计算资源)gzip_disable#正则匹配UA 什么样的Uri不进行gzipgzip_min_length 200# 开始压缩的最小长度(再小就不要压缩了,意义不在)gzip_http_version 1.0|1.1# 开始压缩的http协议版本(可以不设置,目前几乎全是1.1协议)gzip_proxied# 设置请求者代理服务器,该如何缓存内容gzip_types text/plain application/xml# 对哪些类型的文件用压缩 如txt,xml,html ,cssgzip_vary on|off# 是否传输gzip压缩标志

注意:

图片/mp3这样的二进制文件,不必压缩 因为压缩率比较小, 比如100->80字节,而且压缩也是耗费CPU资源的.

比较小的文件不必压缩, nginx的缓存设置 提高网站性能 对于网站的图片,尤其是新闻站, 图片一旦发布, 改动的可能是非常小的.我们希望 能否在用户访问一次后, 图片缓存在用户的浏览器端,且时间比较长的缓存. 可以, 用到 nginx的expires设置 . nginx中设置过期时间,非常简单, 在location或if段里,来写. 格式

expires 30s; expires 30m; expires 2h; expires 30d;

(注意:服务器的日期要准确,如果服务器的日期落后于实际日期,可能导致缓存失效) 另: 304 也是一种很好的缓存手段 原理是: 服务器响应文件内容是,同时响应etag标签(内容的签名,内容一变,他也变), 和 last_modified_since 2个标签值 浏览器下次去请求时,头信息发送这两个标签, 服务器检测文件有没有发生变化,如无,直接头信息返回 etag,last_modified_since 浏览器知道内容无改变,于是直接调用本地缓存. 这个过程,也请求了服务器,但是传着的内容极少. 对于变化周期较短的,如静态html,js,css,比较适于用这个方式

Nginx具体的压缩配置

常用以下配置 gzip on|off gzip_buffers 4K|8K 缓冲(和硬盘块相当) gzip_comp_level [1-9] 推荐6 gzip_disable 正则匹配如User-Agent,针对古老浏览器不压缩 gzip_min_length 200 gzip_http_version 1.0|1.1 gzip_types text/plain , application/xml (各mime之间,一定要加空格,不是逗号) gzip_vary on|off

Vary的作用:

Vary是用来标志缓存的依据. 如上图: 看出,这个新闻页面由

思考: 1: 如果2个人,一个浏览器支持gzip,一个浏览器不支持gzip 2个同时请求同个页面, chinaCache缓存压缩后,还是未压缩的?

2: 如果1人,再次请求页面,chinaCache返回压缩后的缓存内容,还是压缩前的缓存内容?

这个时候 Vary的作用体现出来. 即------缓存的内容受 Accept-Encoding头信息的影响.

所以如果– 请求时,不支持gzip, 缓存服务器将会生成一份未gzip的内容. 请求时,支持gzip, 缓存服务器将会生成一份gzip的内容.

下次再请求时, 缓存服务器会考虑客户端的Accept-Encoding因素,并合理的返回信息

Nginx对于图片,js等静态文件的缓存设置 注:这个缓存是指针对浏览器所做的缓存,不是指服务器端的数据缓存.

主要知识点: location expires指令

location ~ \.(jpg|jpeg|png|gif)$ { expires 1d; } location ~ \.js$ { expires 1h; }

设置并载入新配置文件,用firebug观察, 会发现 图片内容,没有再次产生新的请求,原因–利用了本地缓存的效果.

注: 在大型的新闻站,或文章站中,图片变动的可能性很小,建议做1周左右的缓存Js,css等小时级的缓存.

如果信息流动比较快,也可以不用expires指令, 用last_modified, etag功能(主流的web服务器都支持这2个头信息)

原理是: 响应: 计算响应内容的签名, etag 和 上次修改时间 请求: 发送 etatg, If-Modified-Since 头信息. 服务器收到后,判断etag是否一致, 最后修改时间是否大于if-Modifiled-Since 如果监测到服务器的内容有变化,则返回304, 浏览器就知道,内容没变,直接用缓存.

304 比起上面的expires 指令 多了1次请求, 但是比200状态,少了传输内容.