lighttpd的mod_cache缓存不了的问题

Apr

2009

lighttpd的cache功能一直使用的都比较不错：

1 配置简洁
2 cpu和内存占用不算多，性能良好

但也是有缺点的地方：

1 文件缓存数量巨大时在不断蚕食内存，最好有大内存的服务器做这事，当然了，缓存项目多了自然占用内存多

引用

cache.cached-itmes: 707831
cache.hitrate(%): 18
cache.memory-inuse(KB): 44239
#这个状态会占用了500多M内存

2 文件体系的缓存模式，不知道是否在文件夹文件过多的时候效率不好呢，猜的
3 不知道是否协议上的小问题，导致部分缓存不成功
4 单进程重启有中断

今天是讨论这第三点，在日志里可以找到症状：

引用

2009-04-22 19:18:26: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /
2009-04-22 19:18:37: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /article/4559/
2009-04-22 19:18:44: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /article/4559/
2009-04-22 19:19:01: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /article/4559/
2009-04-22 19:19:09: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /aslibra/com/
2009-04-22 19:19:24: (mod_cache.c.1336) ignore no content-length and no chunked transfer-encoding uri /aslibra/com/

某些PHP处理的请求一直都缓存不上，幸好后端服务器加了缓存控制，否则会疯了的。

我们可以看看mod_cache.c的部分代码：

###井号开始的是我理解的内容
static int check_response_iscachable(server *srv, connection *con, plugin_data *p, handler_ctx *hctx)
....
#只缓存200的响应
if (con->http_status != 200) return 0;
....
#似乎有缓存gzip和deflate的可能
if (p->conf.support_accept_encoding == 0 ) {
  if (p->conf.debug)
    log_error_write(srv, __FILE__, __LINE__, "sb", "ignore response uri with CE", con->uri.path);
  return 0;
} else {
  if (strcasecmp(ds->value->ptr, "gzip") == 0) {
    hctx->content_encoding_type = 1;
  } else if (strcasecmp(ds->value->ptr, "deflate") == 0) {
    hctx->content_encoding_type = 2;
  }
}
....
#不缓存带Set-Cookie的信息
if (NULL != (ds = (data_string *)array_get_element(con->response.headers, "Set-Cookie"))) {
....
#一些cache-control的判断
NULL != (ds = (data_string *)array_get_element(con->response.headers, "Cache-Control")) &&
....
#不缓存比当前时间早的，记得调整服务器时间，否则这里会出问题
(NULL != (ds = (data_string *)array_get_element(con->response.headers, "Expires")))
....
#检查是否有content_length或者chunked标识
if ((p->conf.dynamic_mode == 0) && (con->response.content_length < 0) &&
  !(con->response.transfer_encoding & HTTP_TRANSFER_ENCODING_CHUNKED)) {
  log_error_write(srv, __FILE__, __LINE__, "sb", "ignore no content-length and no chunked transfer-encoding uri", con->uri.path);
  return 0;
}
....

看源代码就是能够理解什么样的响应lighttpd才会缓存了。
一直不太相信最后一个检查居然过不了，日志里面都是这样的提示，因为在直接访问源服务器都是正常的，比如：

引用

(Status-Line)  HTTP/1.0 200 OK
Cache-Control  max-age=1800
Connection  keep-alive
Content-Length  30900
Content-type  text/html
Date  Wed, 22 Apr 2009 13:42:56 GMT
Expires  Wed, 22 Apr 2009 13:57:56 GMT
Server  lighttpd/1.4.19
X-Powered-By  PHP/5.2.6

但是在命令行用curl请求时就不一样了：

引用

[root@localhost log]# curl -I http://123.45.6.7/article/4559/ -H "host:www.aslibra.com"
HTTP/1.1 200 OK
Expires: Wed, 22 Apr 2009 12:26:20 GMT
Cache-Control: max-age=1800
X-Powered-By: PHP/5.2.6
Content-type: text/html
Date: Wed, 22 Apr 2009 12:11:20 GMT
Server: lighttpd/1.4.19

curl的命令是否类似于lighttpd对源服务器proxy请求的呢？
如果是，那就还是在PHP里面处理一下吧：

<?
ob_start();

//your code...

$html = ob_get_contents();
//输出文件长度信息
@header('Content-Length:'.strlen($html));
?>

可以得到正常的信息：

引用

[root@localhost log]# curl -I http://123.45.6.7/article/4559/ -H "host:www.aslibra.com"
HTTP/1.0 200 OK
Connection: close
Expires: Wed, 22 Apr 2009 14:22:24 GMT
Cache-Control: max-age=1800
X-Powered-By: PHP/5.2.6
Content-Length: 28377
Content-type: text/html
Date: Wed, 22 Apr 2009 14:07:24 GMT
Server: lighttpd/1.4.19

cache服务器响应：

引用

(Status-Line)  HTTP/1.1 200 OK
Accept-Ranges  bytes
Cache-Control  max-age=290
Content-Encoding  gzip
Content-Length  8366
Content-Type  text/html
Date  Wed, 22 Apr 2009 14:15:39 GMT
ETag  "-845823938"
Expires  Wed, 22 Apr 2009 14:17:32 GMT
Last-Modified  Wed, 22 Apr 2009 14:12:32 GMT
Server  lighttpd/1.4.19
Vary  Accept-Encoding
X-Cache  HIT
X-Powered-By  PHP/5.2.6

这样应该可以解决此类问题，大家使用愉快。

附录：

lighttpd的cache模块配置：Web Accelerating Cache
官网：http://www.linux.com.cn/modcache/
作者博客：http://blog.quehy.com/

原创内容如转载请注明：来自阿权的书房

收藏本文到网摘