分类目录归档：nginx资料

Nginx模块fastcgi_cache的几个注意点

2016-04-04nginx资料nginxiigadmin

在web项目中，大家都已经非常熟悉其架构流程了。都说Cache是万金油，哪里不舒服抹哪里。这些流程中，几乎每个环节都会进行cache。从浏览器到webserver，到cgi程序，到DB数据库，会进行浏览器cache，数据cache，SQL查询的cache等等。对于fastcgi 这里的cache，很少被使用。去年年底，我对nginx的fastcgi_cache进行摸索使用。在我的测试过程中，发现一些WIKI以及网络上没被提到的注意点，这里分享一下。

从浏览器到数据库的流程图

这里是我的NGinx配置信息

#增加调试信息
add_header X-Cache-CFC "$upstream_cache_status - $upstream_response_time";
fastcgi_temp_path /dev/shm/nginx_tmp;
#cache设置
fastcgi_cache_path   /dev/shm/nginx_cache  levels=1:2 keys_zone=cfcache:10m inactive=50m;
fastcgi_cache_key "$request_method://$host$request_uri";
fastcgi_cache_methods GET HEAD;
fastcgi_cache   cfcache;
fastcgi_cache_valid   any 1d;
fastcgi_cache_min_uses  1;
fastcgi_cache_use_stale error  timeout invalid_header http_500;
fastcgi_ignore_client_abort on;

配置这些参数时，注意每个参数的作用域，像fastcgi_cache_path参数，只能在http配置项里配置，而 fastcgi_cache_min_uses这个参数，可以在http、server、location三个配置项里配置。这样更灵活的会每个域名、每个匹配的location进行选择性cache了。具体的参数作用域，参考FASTCGI模块的官方WIKI。我为了调试方便，添加了一个『X-Cache-CFC』的http响应头，$upstream_cache_status 变量表示此请求响应来自cache的状态，分别为：

MISS 未命中
EXPIRED – expired, request was passed to backend Cache已过期
UPDATING – expired, stale response was used due to proxy/fastcgi_cache_use_stale updating Cache已过期，(被其他nginx子进程)更新中
STALE – expired, stale response was used due to proxy/fastcgi_cache_use_stale Cache已过期，响应数据不合法，被污染
HIT 命中cache

FASTCGI_CACHE $upstream_cache_status 结果为miss，一次也没命中

程序代码是Discuz!论坛，随便开启测试了几下，发现/dev/shm/nginx_cache/下没有任何目录建立，也没有文件创建。调试的http header响应头里的X-Cache-CFC 结果一直是MISS。从服务器进程上来看，Nginx cache manager process 跟Nginx cache loader process 进程也正常运行：

root      3100     1  0 14:52 ?        00:00:00 nginx: master process /usr/sbin/nginx
www-data  3101  3100  0 14:52 ?        00:00:00 nginx: worker process
www-data  3102  3100  0 14:52 ?        00:00:00 nginx: cache manager process
www-data  3103  3100  0 14:52 ?        00:00:00 nginx: cache loader process

不知道为何会这样，为何没有cache成功，我以为我配置参数有问题，只好阅读WIKI。发现fastcgi_ignore_headers 参数下解释有这么一段

fastcgi_ignore_headers
Syntax: fastcgi_ignore_headers field …
Default:
Context: http
server
location
Reference: fastcgi_ignore_headers
This directive forbids processing of the named headers from the FastCGI-server reply. It is possible to specify headers like “X-Accel-Redirect”, “X-Accel-Expires”, “Expires” or “Cache-Control”.

也就是说这个参数的值，将会被忽略掉，同样被忽略掉的响应头比如”X-Accel-Redirect”, “X-Accel-Expires”, “Expires” or “Cache-Control”，而nginx配置中并没有fastcgi_ignore_headers参数的设定，那么问题会不会出现在 FASTCGI响应结果里包含了类似”X-Accel-Redirect”, “X-Accel-Expires”, “Expires” or “Cache-Control”这几个响应头呢？用strace抓包，看了下nginx与fpm进程通讯的数据

####为了确保准确抓到处理该http请求的进程，我把nginx 、fpm都只开启了一个进程处理。
//strace -ff -tt -s 1000 -o xxx.log -p PHPFPM-PID
14:52:07.837334 write(3, "\1\6\0\1\0\343\5\0X-Powered-By: PHP/5.3.10-1ubuntu3.5\r\nExpires: Thu, 19 Nov 1981 08:52:00 GMT\r\nCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0\r\nPragma: no-cache\r\nContent-type: text/html\r\n\r\nHello cfc4n1362034327\0\0\0\0\0\1\3\0\1\0\10\0\0\0\0\0\0\0\0\0\0", 256) = 256
//strace -ff -tt -s 1000 -o xxx.log -p Nginx-PID
15:05:13.265663 recvfrom(12, "\1\6\0\1\0\343\5\0X-Powered-By: PHP/5.3.10-1ubuntu3.5\r\nExpires: Thu, 19 Nov 1981 08:52:00 GMT\r\nCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0\r\nPragma: no-cache\r\nContent-type: text/html\r\n\r\nHello cfc4n1362035113\0\0\0\0\0\1\3\0\1\0\10\0\0\0\0\0\0\0\0\0\0", 4023, 0, NULL, NULL) = 256

从抓取的数据包里可以看到，fpm确实返回了包含“Expires”、“Cache-Control”头的http 响应头信息。那么疑问来了：

nginx的fastcgi_cache没缓存这条http响应，是因为响应头里包含“Expires”、“Cache-Control”的原因吗？
程序里并没有输出“Expires”、“Cache-Control” http header的代码，这是谁输出的呢？
既然是fpm响应的时候，就已经有了，那么是php的core模块，还是其他拓展模块输出的？
“Expires:”时间为何是“Thu, 19 Nov 1981 08:52:00 GMT”?

疑问比较多，一个一个查起，先从Nginx的fastcgi_cache没缓存这条http响应查起。我根据测试环境nginx版本 1.1.9(ubuntu 12.04默认的)，到nginx官方下了对应版本的源码，搜索了fastcgi参数使用的地方，在http\ngx_http_upstream.c找到了。虽然不能很流程的读懂nginx的代码，但粗略的了解，根据了解的情况加以猜测，再动手测试实验，也得出了结论，确定了nginx的 fastcgi_cache的规则。

//ngx_http_upstream.c
//line 3136  当fastcgi响应包含set-cookie时，不缓存
static ngx_int_t
ngx_http_upstream_process_set_cookie(ngx_http_request_t *r, ngx_table_elt_t *h,
    ngx_uint_t offset)
{
#if (NGX_HTTP_CACHE)
    ngx_http_upstream_t  *u;
    u = r->upstream;
    if (!(u->conf->ignore_headers & NGX_HTTP_UPSTREAM_IGN_SET_COOKIE)) {
        u->cacheable = 0;
    }
#endif
    return NGX_OK;
}
//line 3242 当响应头包含Expires时，如果过期时间大于当前服务器时间，则nginx_cache会缓存该响应，否则，则不缓存
static ngx_int_t
ngx_http_upstream_process_expires(ngx_http_request_t *r, ngx_table_elt_t *h,
    ngx_uint_t offset)
{
    ngx_http_upstream_t  *u;
    u = r->upstream;
    u->headers_in.expires = h;
#if (NGX_HTTP_CACHE)
    {
    time_t  expires;
    if (u->conf->ignore_headers & NGX_HTTP_UPSTREAM_IGN_EXPIRES) {
        return NGX_OK;
    }
    if (r->cache == NULL) {
        return NGX_OK;
    }
    if (r->cache->valid_sec != 0) {
        return NGX_OK;
    }
    expires = ngx_http_parse_time(h->value.data, h->value.len);
    if (expires == NGX_ERROR || expires < ngx_time()) {         u->cacheable = 0;
        return NGX_OK;
    }
    r->cache->valid_sec = expires;
    }
#endif
    return NGX_OK;
}
//line 3199  当响应头包含Cache-Control时，#####如果####这里有如果啊。。。
//【注意】如果Cache-Control参数值为no-cache、no-store、private中任意一个时，则不缓存...不缓存...
//【注意】如果Cache-Control参数值为max-age时，会被缓存，且nginx设置的cache的过期时间，就是系统当前时间 + mag-age的值
    if (ngx_strlcasestrn(p, last, (u_char *) "no-cache", 8 - 1) != NULL
        || ngx_strlcasestrn(p, last, (u_char *) "no-store", 8 - 1) != NULL
        || ngx_strlcasestrn(p, last, (u_char *) "private", 7 - 1) != NULL)
    {
        u->cacheable = 0;
        return NGX_OK;
    }
    p = ngx_strlcasestrn(p, last, (u_char *) "max-age=", 8 - 1);
    if (p == NULL) {
        return NGX_OK;
    }
    ...
    r->cache->valid_sec = ngx_time() + n;

也就是说，fastcgi响应http请求的结果中，响应头包括Expires、Cache-Control、Set-Cookie三个，都会可能不被cache，但不只有这些，别忘了nginx配置中fastcgi_ignore_headers参数设定的部分。以及ngxin的X-ACCEL X-Accel-Redirect、X-Accel-Expires、X-Accel-Charset、X-Accel-Buffering等nginx 自定义的响应头。由于这几个不常用，我也没深入研究。通过对nginx的ngx_http_upstream模块代码模糊理解，加猜测，以及写了脚本测试验证，可以得到结论是正确的。即Nginx fastcgi_cache在缓存后端fastcgi响应时，当响应里包含“set-cookie”时，不缓存;当响应头包含Expires时，如果过期时间大于当前服务器时间，则nginx_cache会缓存该响应，否则，则不缓存;当响应头包含Cache-Control时，如果Cache- Control参数值为no-cache、no-store、private中任意一个时，则不缓存，如果Cache-Control参数值为max- age时，会被缓存，且nginx设置的cache的过期时间，就是系统当前时间 + mag-age的值。

nginx fastcgi_cache 响应expired

nginx fastcgi_cache hit命中

FASTCGI_CACHE $upstream_cache_status 结果为miss，一次也没命中。

//逐个测试，测试时，注释其他的
header("Expires: ".gmdate("D, d M Y H:i:s", time()+10000).' GMT');
header("Expires: ".gmdate("D, d M Y H:i:s", time()-99999).' GMT');
header("X-Accel-Expires:30");
header("Cache-Control: no-cache");
header("Cache-Control: no-store");
header("Cache-Control: private");
header("Cache-Control: max-age=10");
setcookie('cfc4n',"testaaaa");
echo 'Hello cfc4n',time();

到了这里，疑问1解决了。那么疑问2、3呢？程序里并没有输出“Expires”、“Cache-Control” http header的代码，这是谁输出的呢？既然是fpm响应的时候，就已经有了，那么是php的core模块，还是其他拓展模块输出的？我精简了代码，只输出一个“hello world”，发现也确实被缓存了。显然，php脚本程序中并没输出http header 的“Expires”、“Cache-Control”，多次测试，最终定位到session_start函数，翻阅源码找到了这些代码：

//ext/session/session.c  line:1190 左右
// ...
CACHE_LIMITER_FUNC(private) /* {{{ */
{
    ADD_HEADER("Expires: Thu, 19 Nov 1981 08:52:00 GMT");
    CACHE_LIMITER(private_no_expire)(TSRMLS_C);
}
/* }}} */
//再到这里3 或者上面几个 ##默认是nocache
CACHE_LIMITER_FUNC(nocache) /* {{{ */
{
    ADD_HEADER("Expires: Thu, 19 Nov 1981 08:52:00 GMT");
    /* For HTTP/1.1 conforming clients and the rest (MSIE 5) */
    ADD_HEADER("Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
    /* For HTTP/1.0 conforming clients */
    ADD_HEADER("Pragma: no-cache");
}
/* }}} */
//这里2
static php_session_cache_limiter_t php_session_cache_limiters[] = {
    CACHE_LIMITER_ENTRY(public)
    CACHE_LIMITER_ENTRY(private)
    CACHE_LIMITER_ENTRY(private_no_expire)
    CACHE_LIMITER_ENTRY(nocache)
    {0}
};
static int php_session_cache_limiter(TSRMLS_D) /* {{{ */
{
    php_session_cache_limiter_t *lim;
    if (PS(cache_limiter)[0] == '\0') return 0;
    if (SG(headers_sent)) {
        const char *output_start_filename = php_output_get_start_filename(TSRMLS_C);
        int output_start_lineno = php_output_get_start_lineno(TSRMLS_C);
        if (output_start_filename) {
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send session cache limiter - headers already sent (output started at %s:%d)", output_start_filename, output_start_lineno);
        } else {
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send session cache limiter - headers already sent");
        }
        return -2;
    }
    for (lim = php_session_cache_limiters; lim->name; lim++) {
        if (!strcasecmp(lim->name, PS(cache_limiter))) {
            lim->func(TSRMLS_C);   //这里1
            return 0;
        }
    }
    return -1;
}
// ...

到了这里，知道原因了，是程序调用session_start时，php的session拓展自己输出的。session.cache_limit 参数来决定输出包含哪种Expires的header，默认是nocache，修改php.ini的session.cache_limit参数为 “none”即可让session模块不再输出这些http 响应头。或在调用session_start之前，使用session_cache_limiter函数来指定下该参数值。那为什么要在使用 session时，发Expires、Cache-Control的http response header呢？我猜测了下，需要session时，基本上是用户跟服务器有交互，那么，既然有交互，就意味着用户的每次交互结果也可能不一样，就不能 cache这个请求的结果，给返回给这个用户。同时，每个用户的交互结果都是不一样的，nginx也就不能把包含特殊Cache-Control的个人响应cache给其他人提供了。

还有一个无聊的问题“Expires:时间为何是Thu, 19 Nov 1981 08:52:00 GMT”？我翻阅了session.c这段代码的添加时间，版本，作者信息，在php官方版本库中找到了这次提交的信息：

Revision 17092 – (view) (download) (as text) (annotate) – [select for diffs]
Modified Sun Dec 12 14:16:55 1999 UTC (13 years, 2 months ago) by sas
File length: 28327 byte(s)
Diff to previous 16964
Add cache_limiter and cache_expire options. Rename extern_referer_check
to referer_check.

对比session.c两个版本的变更，果然是这块代码。作者是sas，也就是Sascha Schumann， http://php.net/credits.php里可以看到他的大名。关于这个expires过期时间的问题，有人在stackoverflow也提问过，Why is “Expires” 1981?，别人说那天是他生日。这是真的么？如果那天是他生日的话，而他增加session.cache_limiter时是1999年，他才17岁，17岁呀。我17岁时在干嘛？还不知道电脑长啥样，正在玩『超级玛丽』呢。

好奇的不是我一个人，还有个帖子是epoch date — Expires: Thu, 19 Nov 1981 08:52:00也问了。另外两个地址虽然没问，也有人提到那天是他生日了。http://boinc.berkeley.edu/dev/forum_thread.php?id=2514、https://github.com/codeguy/Slim/issues/157，这些帖子都提到说原帖是http://www.phpbuilder.com/lists/php3-list/199911/3159.php ，我无法访问，被跳转到首页了。用http://web.archive.org找到了历史快照，发现上下文关系不大，也不能证明是他生日。我更是好奇的发了两封邮件到他的不同邮箱里问他，不过，目前他还没回复。或许他没收到、没看到，或许懒得回了。N年后，“Expires:时间为何是Thu, 19 Nov 1981 08:52:00 GMT”这个日期，会不会又成了一段奇闻佳话了呢？

来源：http://www.cnxct.com/several-reminder-in-nginx-fastcgi_cache-and-php-session_cache_limiter/

srcache_nginx redis 构建缓存系统应用一例

2015-11-18nginx资料nginx， redisiigadmin

redis是一种高效的key-value存储。srcache_nginx模块相关参数介绍，可以参见《memc_nginx+srcache_nginx+memcached构建透明的动态页面缓存》。

下面举一例应用，看配置：

upstream redis {
server 127.0.0.1:6380;
keepalive 512;
}server {
listen 80 backlog=1024 default;
server_name www.ttlsa.com;
index index.html index.htm index.php;
root /data/wwwroot/www.ttlsa.com/webroot;

location / {
set $flag 0;
if ($uri ~ /thumb/[0-9]+_160.jpg$){
set $flag "${flag}1";
}
if ($arg_unitid = 42012){
set $flag "${flag}1";
}
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php?kohana_uri=$1 last;
}
}
location ~ .*\.php?$ {
srcache_store_private on;
srcache_methods GET;
srcache_response_cache_control off;
if ($flag = "011"){
set $key $request_uri;
set_escape_uri $escaped_key $key;
srcache_fetch GET /redis $key;
srcache_default_expire 172800;
srcache_store PUT /redis2 key=$escaped_key&exptime=$srcache_expire;

add_header X-flag $flag;
add_header X-Cached-From $srcache_fetch_status;
add_header X-Cached-Store $srcache_store_status;
add_header X-Key $key;
set_md5 $md5key $key;
add_header X-md5-key $md5key;
add_header X-Query_String $query_string;
add_header X-expire $srcache_expire;
}
include fastcgi_params;
fastcgi_pass 127.0.0.1:10080;
fastcgi_index index.php;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location = /redis {
internal;
set_md5 $redis_key $args;
redis_pass redis;
}

location = /redis2 {
internal;

set_unescape_uri $exptime $arg_exptime;
set_unescape_uri $key $arg_key;
set_md5 $key;

redis2_query set $key $echo_request_body;
redis2_query expire $key $exptime;
redis2_pass redis;
}
}

测试：

redis实例下：

可以记录下日志来测试加缓存前后的耗时。日志格式如下：

log_format srcache_log '$remote_addr - $remote_user [$time_local] "$request" '
'"$status" $body_bytes_sent $request_time $bytes_sent $request_length '
'[$upstream_response_time] [$srcache_fetch_status] [$srcache_store_status] [$srcache_expire]';

转载请注明来自运维生存时间: http://www.ttlsa.com/html/3952.html

使用memc-nginx和srcache-nginx模块构建高效透明的缓存机制

2015-10-18nginx资料nginxiigadmin

Nginx的Memc和SR Cache模块

缓存策略的改进

为了提高性能，几乎所有互联网应用都有缓存机制，其中Memcache是使用非常广泛的一个分布式缓存系统。众所周知，LAMP是非常经典的Web架构方式，但是随着Nginx的成熟，越来越多的系统开始转型为LNMP（Linux+Nginx+MySQL+PHP with fpm），这是因为Nginx采用基于事件机制的I/O多路复用思想设计，在高并发情况下其性能远远优于默认采用prefork模式的Apache，另外，相对于Apache，Nginx更轻量，同时拥有大量优秀的扩展模块，使得在Nginx上可以实现一些美妙的功能。

传统上，PHP中使用memcache的方法是使用php-memcache或php-memached扩展操作Memcache，然而在Nginx上有构建更高效缓存机制的方法，本文将首先介绍这种机制，然后介绍具体的操作步骤方法，最后将对这种机制和传统的PHP操作memcache的性能进行一个benchmark。

我们知道，Nginx的核心设计思想是事件驱动的非阻塞I/O。

Nginx被设计为可以配置I/O多路复用策略，在Unix系统中传统的多路复用是采用select或poll，但是这两个方法的问题是随着监听 socket的增加，性能会下降，因为在linux内核中是采用轮询的方式判断是否可以触发事件，换句话说算法的复杂度为O(N)，而在较新的linux 内核中引入了复杂度为O(1)的epoll，因此Nginx在Linux下默认采用epoll，而在FreeBSD下默认采用kqueue作为I/O策略。

即便是这样，传统的缓存策略仍可能造成效率低下，因为传统上是通过PHP操作memcache的，要执行PHP代码，Nginx就必然要和FastCGI 通信，同时也要进入PHP的生命周期，因此SAPI、PHP Core和Zend Engine的一系列逻辑会被执行。更糟糕的是，fpm和PHP可能会阻塞，因此破坏了Nginx的非阻塞性。（原文中此处表述有误，fastcgi与 nginx进行同步通信，但并不会破坏nginx i/o的非阻塞性，多谢agentzh给予指正）下图展示了在memcache命中时整个处理过程。

可以看到，即使Memcache命中，还是要进入PHP的生命周期。我们知道，目前很多互联网应用都使用RESTful规范进行设计，在RESTful应用下，普遍使用uri和查询参数作为缓存的key，因此一种更高效的缓存策略是Nginx直接访问Memcache，并用$uri和$args等 Nginx内置变量设定缓存key规则，这样，当缓存命中时，Nginx可以跳过通过fastcgi和PHP通信的过程，直接从memcache中获取数据并返回。memc-nginx和srcache-nginx正是利用这种策略提高了缓存的效率。下图是这种高效缓存策略的示意图（当memcache命中时）。

模块介绍

memc-nginx和srcache-nginx模块均为前淘宝工程师agentzh（章亦春）开发。其中memc模块扩展了Nginx标准的memcache模块，增加了set、add、delete等 memcache命令，而srcache则是为location增加了透明的基于subrequest的缓存层。两者配合使用，可以实现上一节提到的高效缓存机制。关于两个模块的详细信息可以参考它们Nginx官网的wiki（memc wiki，srcache wiki）页。

安装及配置

下面以LNMP环境介绍如何使用这两个模块构建缓存层。

因为Nginx并不支持模块动态加载，所以要安装新的模块，必须重新编译Nginx。首先下载两个模块（memc下载地址，srcache下载地址），另外，为了发挥出缓存的最大性能，建议将memcache的upstream配置为keep-alive，为了支持upstream的keep-alive需要同时安装http-upstream-keepalive-module。

将模块下载并解压到合适的目录，这里我Nginx使用的版本是1.0.4，与相关模块一起解压到了/home/www/download

然后就可以编译安装Nginx了，命令如下：

./configure --prefix=/usr/local/nginx \
--add-module=../memc-nginx-module \
--add-module=../srcache-nginx-module \
--add-module=../ngx_http_upstream_keepalive
make
make install

这里我将nginx安装到/usr/local/nginx下，你可以根据自己的需要更改安装路径，另外，我只列出了本文必要的configure命令，你也可以增加需要的configure选项。
然后需要对nginx进行配置，nginx默认主配置文件放在安装目录的conf下，例如我的主配置文件为/usr/local/nginx/conf/nginx.conf。
这里我只贴出相关的配置：

#Memcache服务upstream
upstream memcache {
    server localhost:11211;
    keepalive 512 single;
}
server {
    listen       80;
    server_name  localhost;
    #memc-nginx-module
    location /memc {
        internal;
        memc_connect_timeout 100ms;
        memc_send_timeout 100ms;
        memc_read_timeout 100ms;
        set $memc_key $query_string;
        set $memc_exptime 300;
        memc_pass memcache;
    }
    location / {
        root   /var/www;
        index  index.html index.htm index.php;
    }
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        charset        utf-8;
        default_type   text/html;
        #srcache-nginx-module
        set $key $uri$args;
        srcache_fetch GET /memc $key;
        srcache_store PUT /memc $key;
        root           /var/www;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

下面解释一下其中几个点。
上文说过，memc-nginx是一个标准的upstream模块，因此首先需要定义memcache的upstream。这里我在本机上启动了一个 memcache服务，端口为默认的11211，keepalive指令是http-upsteram-keepalive-module提供的功能，这里我们最大保持512个不立即关闭的连接用于提升性能。

下面是为memc-nginx-module配置location，我们配置为/memc，所有请求都通过请求这个location来操作 memcache，memc-nginx-module存取memcache是基于http method语义的，使用http的GET方法表示get、PUT方法表示set、DELETE方法表示delete。这里我们将/memc设为internal表示只接受内部访问，不接收外部http请求，这是为了安全考虑，当然如果需要通过http协议开放外部访问，可以去掉internal然后使用deny和allow指令控制权限。比较重要的是$memc_key这个变量，它表示以什么作为key，这里我们直接使用Nginx内置的$query_string来作为 key，$memc_exptime表示缓存失效时间，以秒记。这里统一设为300（5分钟），在实际应用中可以根据具体情况为不同的内容设置不同的过期时间。

最后我们为“~ \.php$”这个location配置了缓存，这表示所有以“.php”结尾的请求都会结果被缓存，当然这里只是示例需要，实际中一般不会这么配，而是为特定需要缓存的location配置缓存。

srcache_fetch表示注册一个输入拦截处理器到location，这个配置将在location进入时被执行；而srcache_store表示注册一个输出拦截器到location，当location执行完成并输出时会被执行。注意srcache模块实际可以与任何缓存模块进行配合使用，而不必一定是memc。这里我们以$uri$args作为缓存的key。

经过上述配置后，相当于对Nginx增加了如下逻辑：当所请求的uri以“.php”结尾时，首先到memcache中查询有没有以$uri$args为 key的数据，如果有则直接返回；否则，执行location的逻辑，如果返回的http状态码为200，则在输出前以$uri$args为key，将输入结果存入memcache。

Benchmark

下面对使用memc和srcache构建的缓存机制进行一个简单的benchmark，并与使用PHP操作memcache的策略进行一个对比。为了简单起见，我们的测试PHP脚本不去访问I/O，而仅仅是调用phpinfo函数输出PHP相关信息。
测试一共分三组进行：第一组在Nginx和PHP中均不开启缓存，第二组仅使用PHP memcache缓存，第三组仅使用Nginx memcache缓存。三组都用ab程序去压，并发数为20，请求次数为10000。
这里的测试环境是我的一个虚拟机，操作系统为Ubuntu10，内存512M。Nginx采用epoll，单worker进程，memcache最大并发数为1024，最大使用内存64m。

不开启缓存

这一组我们不开启缓存，PHP程序非常简单：

<?php
phpinfo();
?>

测试结果如下：

PHP memcache缓存策略

第二组我们用PHP操作缓存，测试脚本为：

<?php
$memc = new Memcached;
$memc->addServer('localhost', 11211) or die('Connect to memcache server failed!');
$output = $memc->get('my_key');
if(empty($output)) {
    ob_start();
    phpinfo();
    $output = ob_get_contents();
    ob_end_clean();
    $memc->set('my_key', $output, 300);
}
echo $output; 
?>

测试结果如下：

Nginx memcache缓存策略

最后，我们将PHP脚本回归到不使用缓存的版本，并配置好memc和srcache缓存机制。
测试结果如下：

结果对比分析

为了直观，我取“每秒处理请求数”、“平均每个请求处理时间”和“吞吐率”作为评价指标，制作了一张图表。

我想看到图表，结论已毋需我多言。在各项指标上使用memc和srcache构建的缓存机制都大大优于使用PHP操作memcache。其中每秒处理请求数（并发度）和吞吐率都是其9倍左右，而平均个请求所用时间仅有传统策略的1/8。

这里要特别说明一下，这里之所以PHP memcache策略比不使用缓存优势不明显，是因为我们的PHP脚本不涉及I/O操作，如果其中存在如数据库存取，PHP memcache的优势还是有的，但不论如何，Nginx memcache策略在性能上的优势是其无法比拟的。

另外，除了性能优势外，使用这种策略还可以简化PHP逻辑，因为缓存这一层都放在Nginx中了，PHP就从缓存操作中解放了出来，因此是一举多得。

如果你的系统也构建在LNMP上（或LAMP）上，不妨使用本文提到的方法替代传统的缓存策略，尽情享受性能上的提升。

转载：张洋个人博客 --- 使用memc-nginx和srcache-nginx模块构建高效透明的缓存机制

来源：http://www.qixing318.com/article/using-memc-nginx-and-srcache-nginx-module-build-efficient-and-transparent-caching-mechanism.html

安装OpenResty

2015-03-20nginx资料nginxiigadmin

OpenResty，也被称为“ngx_openresty”，是一个基于Nginx的核心Web应用程序服务器，它包含了大量的第三方的Nginx模块和大部分系统依赖包。 OpenResty不是Nginx的分支，它只是一个软件包。主要有章亦春维护。
为什么是OpenResty？

OpenResty （也称为 ngx_openresty）是一个全功能的 Web 应用服务器。它打包了标准的 Nginx 核心，很多的常用的第三方模块，以及它们的大多数依赖项。

通过众多进行良好设计的 Nginx 模块，OpenResty 有效地把 Nginx 服务器转变为一个强大的 Web 应用服务器，基于它开发人员可以使用 Lua 编程语言对 Nginx 核心以及现有的各种 Nginx C 模块进行脚本编程，构建出可以处理一万以上并发请求的极端高性能的 Web 应用。

OpenResty 致力于将你的服务器端应用完全运行于 Nginx 服务器中，充分利用 Nginx 的事件模型来进行非阻塞 I/O 通信。不仅仅是和 HTTP 客户端间的网络通信是非阻塞的，与MySQL、PostgreSQL、Memcached、以及 Redis 等众多远方后端之间的网络通信也是非阻塞的。

因为 OpenResty 软件包的维护者也是其中打包的许多 Nginx 模块的作者，所以 OpenResty 可以确保所包含的所有组件可以可靠地协同工作。
安装OpenResty
依赖的软件包：
perl 5.6.1+
libreadline
libpcre
libssl

Debian 和 Ubuntu系统：
apt-get install libreadline-dev libncurses5-dev libpcre3-dev libssl-dev perl make

Fedora 、RedHat 和 centos系统：
yum install readline-devel pcre-devel openssl-devel

下载OpenResty
wget http://openresty.org/download/ngx_openresty-1.5.8.1.tar.gz.

解压、编译、安装：
tar xzvf ngx_openresty-1.5.8.1.tar.gz
cd ngx_openresty-1.5.8.1/
./configure --with-luajit
make
make install

另外的配置选项：
./configure --prefix=/opt/openresty
--with-luajit
--without-http_redis2_module
--with-http_iconv_module
--with-http_postgres_module
-j2
--help to see more options

参考资料：

官方: http://openresty.org/
Github: https://github.com/agentzh/ngx_openresty

来源：http://www.ttlsa.com/nginx/how-to-install-openresty/

https安装(2)nginx配置

2013-09-28nginx资料nginx

原创文章，转载请指明出处并保留原文url地址

现在网络完全越来越受到重视，因此https也是大势所趋，以往nginx都是工作在http方式下，其实nginx在https下工作也挺好的。这里将分步骤的逐步实现一套采用nginx， haproxy， keepalived实现的https系统，并且系统没有单点故障，基本适应中小系统的安全需要。

1. Nginx https安装这个文章主要是安装支持https的nginx，源代码装过程

2. https安装(2)nginx配置（本文）继承上一个文章，记录配置过程，然后实现https服务

3. 两台nginx实现https负载均衡介绍通过haproxy实现两个nginx的负载均衡，解决nginx的单点故障

前一篇文章 Nginx https安装

1. 配置nginx服务器

进入nginx的安装目录

[root@iig conf]# cat nginx.conf

worker_processes  1;
events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    
    server {
        listen       80;
        server_name  www.iigrowing.cn;
        location / {
            root   www.iigrowing.cn;
            index  index.html index.htm;
        }
    }
}

2. 生成证书

进入证书的目录cd /etc/pki/tls/certs/，创建证书然后设置密码

make rsyslog.key

[root@iig certs]# openssl rsa -in rsyslog.key -out rsyslog.key

Enter pass phrase for rsyslog.key:

writing RSA key

[root@iig certs]#

3. 创建证书rsyslog.csr

在创建的时候需要注意要的是要写对计算机名字，可以用hostname来查看。

[root@iig certs]# hostname

iig.local.ftp

[root@iig certs]# make rsyslog.csr

umask 77 ; \

/usr/bin/openssl req -utf8 -new -key rsyslog.key -out rsyslog.csr

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [GB]:GB

State or Province Name (full name) [Berkshire]:beijing

Locality Name (eg, city) [Newbury]:beijing

Organization Name (eg, company) [My Company Ltd]:www.iigrowing.cn

Organizational Unit Name (eg, section) []:iigrowing

Common Name (eg, your name or your server's hostname) []:iig.local.ftp

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

4．生成证书机构用于颁发公钥

因为我们是在本地生成的没有在互联网CA证书机构颁发证书，因此在访问的时候会弹出浏览器警告，我们添加到证书信任机构就可以了。

[root@iig certs]#

[root@iig certs]# openssl x509 -in rsyslog.csr -req -signkey rsyslog.key -days 365 -out rsyslog.crt

Signature ok

subject=/C=GB/ST=beijing/L=beijing/O=www.iigrowing.cn/OU=iigrowing/CN=iig.local.ftp

Getting Private key

[root@iig certs]#

5．修改nginx配置文件

修改配置文件，需要注意的是我们把默认的ssl模块复制到我们创建的虚拟目录里面即可，默认的不要打开，然后修改路径即可。如图是完成的配置。记得重启服务。

worker_processes 1;

events {

worker_connections 1024;

}

http {

include mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65;

server {

listen 80;

server_name www.iigrowing.cn;

location / {

root www.iigrowing.cn;

index index.html index.htm;

}

server {

listen 443;

server_name www.iigrowing.cn;

ssl on;

ssl_certificate /etc/pki/tls/certs/rsyslog.crt;

ssl_certificate_key /etc/pki/tls/certs/rsyslog.key;

ssl_session_timeout 5m;

ssl_protocols SSLv2 SSLv3 TLSv1;

ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

ssl_prefer_server_ciphers on;

location / {

root www.iigrowing.cn;

index index.html index.htm;

}

6．测试https协议

在如下目录, 创建a.txt文件, 内容如下图

打开浏览器, 输入如下地址: https://www.iigrowing.cn/a.txt

显示结果

快乐成长

每天进步一点点

缓存策略的改进

模块介绍

安装及配置

更多配置

Benchmark

不开启缓存

PHP memcache缓存策略

Nginx memcache缓存策略

结果对比分析

1. 配置nginx服务器

2. 生成证书

3. 创建证书rsyslog.csr

4． 生成证书机构用于颁发公钥

5． 修改nginx配置文件

6． 测试https协议

4．生成证书机构用于颁发公钥

5．修改nginx配置文件

6．测试https协议