关于lighttpd的资料
lighttpd可以rewrite地址到一个php文件处理所有相关的请求，比如：
这个/是从网站根目录开始算的，所以不能指定其它目录的文件
需要制定其它目录的文件，那可以先alias处理，比如
先定义一个本地文件为文件系统的另外一个文件
然后rewrite到此文件即可！
url.rewrite-once = (
"^/c/" => "/page_c.php"
)
"^/c/" => "/page_c.php"
)
这个/是从网站根目录开始算的，所以不能指定其它目录的文件
需要制定其它目录的文件，那可以先alias处理，比如
$HTTP["host"] == "www.aslibra.com" {
server.document-root = "/Data/webapps/www.aslibra.com"
alias.url = (
"/page_c.php" => "/Data/webapps/test.aslibra.com/page_c.php"
)
url.rewrite-once = (
"^/c/" => "/page_c.php"
)
}
server.document-root = "/Data/webapps/www.aslibra.com"
alias.url = (
"/page_c.php" => "/Data/webapps/test.aslibra.com/page_c.php"
)
url.rewrite-once = (
"^/c/" => "/page_c.php"
)
}
先定义一个本地文件为文件系统的另外一个文件
然后rewrite到此文件即可！
今日发现lighttpd的日志有大量的错误是同样的错误提示：
因为存在11433/1 的下级目录，而lighttpd根据地址认为 11433 是一个文件，删除的时候出错了，代码位置是：
unlink只能删除文件，不能删除文件夹，所以删除失败。
在linux下同一个目录下不会有同名的文件和文件夹
也就是说，如果 /a/1 的地址先访问，/a/1 的文件就先创建了
如果 /a/1/index.htm 先访问，/a/1 的文件夹先创建，老外一种形式就无法再缓存，这个就给后端带来了压力。
这个可以用redirect或者rewrite修正，参考做法：
2009-05-21 18:39:06: (mod_cache.c.2080) failed to delete old cache file /cache/web/www.aslibra.com/search/article/11433 before update Is a directory
因为存在11433/1 的下级目录，而lighttpd根据地址认为 11433 是一个文件，删除的时候出错了，代码位置是：
if (unlink(file->ptr) && errno != ENOENT) {
log_error_write(srv, __FILE__, __LINE__, "sbss", "failed to delete old cache file",
hctx->file, "before update", strerror(errno));
log_error_write(srv, __FILE__, __LINE__, "sbss", "failed to delete old cache file",
hctx->file, "before update", strerror(errno));
unlink只能删除文件，不能删除文件夹，所以删除失败。
在linux下同一个目录下不会有同名的文件和文件夹
[root@localhost test]# ll
total 8
-rw-r--r-- 1 root root 1 May 24 02:08 a
[root@localhost test]# mkdir a
mkdir: `a' exists but is not a directory
[root@localhost test]# mkdir b
[root@localhost test]# ll
total 16
-rw-r--r-- 1 root root 1 May 24 02:08 a
drwxr-xr-x 2 root root 4096 May 24 02:16 b
[root@localhost test]# echo>b
-bash: b: Is a directory
total 8
-rw-r--r-- 1 root root 1 May 24 02:08 a
[root@localhost test]# mkdir a
mkdir: `a' exists but is not a directory
[root@localhost test]# mkdir b
[root@localhost test]# ll
total 16
-rw-r--r-- 1 root root 1 May 24 02:08 a
drwxr-xr-x 2 root root 4096 May 24 02:16 b
[root@localhost test]# echo>b
-bash: b: Is a directory
也就是说，如果 /a/1 的地址先访问，/a/1 的文件就先创建了
如果 /a/1/index.htm 先访问，/a/1 的文件夹先创建，老外一种形式就无法再缓存，这个就给后端带来了压力。
这个可以用redirect或者rewrite修正，参考做法：
$HTTP["host"] == "www.aslibra.com" {
#指定规则补全地址
url.redirect = (
"^/search/(article|pic)/([^/]+)$" => "/search/$1/$2/",
)
$HTTP["url"] =~ "^/search/" {
#可以重新制定目录缓存文件，避免原先的文件冲突
cache.bases = ("/cache/web/search/")
cache.support-queries = "disable"
}
proxy.server = ( "" =>(
( "host" => "192.168.1.2")
))
}
#指定规则补全地址
url.redirect = (
"^/search/(article|pic)/([^/]+)$" => "/search/$1/$2/",
)
$HTTP["url"] =~ "^/search/" {
#可以重新制定目录缓存文件，避免原先的文件冲突
cache.bases = ("/cache/web/search/")
cache.support-queries = "disable"
}
proxy.server = ( "" =>(
( "host" => "192.168.1.2")
))
}
一直使用lighttpd的modcache，作者博客是：
http://blog.quehy.com/
我一直不理解quehy是什么意思，query的变异？还是英文名？今天无意中看到人物介绍才理解意思:
出自：http://www.sysbus.com/?p=184
从名字我就知道域名的意思了，原来是强人一个，我也很希望以后能做点开源项目。
他启动的两个开源项目我都非常喜欢：
1 lighttpd的modcache
我一直在使用，已经代替了squid的位置，使用效果还是不错的
2 memagent
这个也很实用，一直也在考虑加强memcached的稳定性的问题，看来这又给我带来了解决方案
http://blog.quehy.com/
我一直不理解quehy是什么意思，query的变异？还是英文名？今天无意中看到人物介绍才理解意思:
引用
不知道你有没有印象，之前我介绍的magent就出自该牛人，顺便八卦一下，google了一下，果然强
“阙宏宇是一名传奇人物。阙宏宇却连跳数级，15岁便一举考中清华大学自动系，19岁被保送到中国科学院计算机系攻读硕士研究生。毕业后历任Chinaren校友录的技术总监和sohu无线事业部总监，sohu网站的闪电邮系统和chinaren的校友录架构都是以他为主开发的。”
“阙宏宇是一名传奇人物。阙宏宇却连跳数级，15岁便一举考中清华大学自动系，19岁被保送到中国科学院计算机系攻读硕士研究生。毕业后历任Chinaren校友录的技术总监和sohu无线事业部总监，sohu网站的闪电邮系统和chinaren的校友录架构都是以他为主开发的。”
出自：http://www.sysbus.com/?p=184
从名字我就知道域名的意思了，原来是强人一个，我也很希望以后能做点开源项目。
他启动的两个开源项目我都非常喜欢：
1 lighttpd的modcache
我一直在使用，已经代替了squid的位置，使用效果还是不错的
2 memagent
这个也很实用，一直也在考虑加强memcached的稳定性的问题，看来这又给我带来了解决方案
lighttpd的cache功能一直使用的都比较不错：
1 配置简洁
2 cpu和内存占用不算多，性能良好
但也是有缺点的地方：
1 文件缓存数量巨大时在不断蚕食内存，最好有大内存的服务器做这事，当然了，缓存项目多了自然占用内存多
2 文件体系的缓存模式，不知道是否在文件夹文件过多的时候效率不好呢，猜的
3 不知道是否协议上的小问题，导致部分缓存不成功
4 单进程重启有中断
今天是讨论这第三点，在日志里可以找到症状：
某些PHP处理的请求一直都缓存不上，幸好后端服务器加了缓存控制，否则会疯了的。
1 配置简洁
2 cpu和内存占用不算多，性能良好
但也是有缺点的地方：
1 文件缓存数量巨大时在不断蚕食内存，最好有大内存的服务器做这事，当然了，缓存项目多了自然占用内存多
引用
cache.cached-itmes: 707831
cache.hitrate(%): 18
cache.memory-inuse(KB): 44239
#这个状态会占用了500多M内存
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/
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处理的请求一直都缓存不上，幸好后端服务器加了缓存控制，否则会疯了的。
图：更换lighttpd+php fast-cgi的变化
原先服务器是apache的，加载php5模块，还有mysql运行，但一直负载很高，把mysql用到局域网的另外一个机器，占用CPU更加高，快疯了。可能apache进程太多，每个进程都吃太多内存了？具体原因不知道。
昨天晚上把php-fastcgi安装好了，打包文件见新浪的资料共享：
http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=4537134
安装好后，把apache的日志对应lighttpd写好，转换好之前的配置，然后发现一个问题，rewrite后的url已经是变化了的，大家要注意（示例说明）：
$HTTP["host"] == "test.aslibra.com" {
url.rewrite-once = (
"^/s" => "/__s.php",
)
server.document-root = "/Data/webapps/test.aslibra.com"
$HTTP["url"] =~ "^\/__s" {
accesslog.filename = "|/Data/apps/cronolog/sbin/cronolog /log/%Y/%m/%d/sub.%m%d%H"
}
}
url.rewrite-once = (
"^/s" => "/__s.php",
)
server.document-root = "/Data/webapps/test.aslibra.com"
$HTTP["url"] =~ "^\/__s" {
accesslog.filename = "|/Data/apps/cronolog/sbin/cronolog /log/%Y/%m/%d/sub.%m%d%H"
}
}
启动后，负载变轻了好多好多，流量还正常。
看来php的fast-cgi应该好好配置好，apache的确有点重了。。
不过今天有发现假死情况，重启也无法启动lighttpd，不知道是否php-cgi占用内存多了还是啥，有待观察。。。
今天发现上传不了图片了，还以为是程序出问题了。
PHP上传文件是类似的错误
检查磁盘，网站目录都还正常，还有200G空间呢，不可能出现这样的问题。就发现根目录已经使用了百分之九十多了，具体数值忘记了，可能是系统保护的预留的空间。
重启了一下lighttpd，发现有如下提示：
第一个是lighttpd的compress的模块，是写入文件的
第二个是XCache的临时目录写入
第三个是php的socket文件
看来是tmp目录所在的分区满了。
大体应该是lighttpd使用的压缩文件占用空间越来越大，导致空间不足，把lighttpd的compress目录重新设置到富裕的分区就好，然后把tmp目录的压缩文件目录都删掉即可。
PHP上传文件是类似的错误
引用
Array(
[name] => 1711.jpg
[type] =>
[tmp_name] =>
[error] => 6
[size] => 0
)
[name] => 1711.jpg
[type] =>
[tmp_name] =>
[error] => 6
[size] => 0
)
检查磁盘，网站目录都还正常，还有200G空间呢，不可能出现这样的问题。就发现根目录已经使用了百分之九十多了，具体数值忘记了，可能是系统保护的预留的空间。
重启了一下lighttpd，发现有如下提示：
引用
2008-10-16 11:50:49: (mod_compress.c.415) couldn't create directory for file /tmp/lighttpd/cache/compress/12798222/index.htm-gzip-64391395-13510-1215020773
[root@localhost lighttpd]# xc_fcntl_create: open(/tmp/.xcache.2.0.1804289383.lock, O_RDWR|O_CREAT, 0666) failed:PHP Fatal error: XCache: can't create lock in Unknown on line 0
PHP Fatal error: XCache: failed init opcode cache in Unknown on line 0
[root@localhost lighttpd]# 2008-10-16 11:53:50: (mod_fastcgi.c.1743) connect failed: No such file or directory on unix:/tmp/php.socket-3
[root@localhost lighttpd]# xc_fcntl_create: open(/tmp/.xcache.2.0.1804289383.lock, O_RDWR|O_CREAT, 0666) failed:PHP Fatal error: XCache: can't create lock in Unknown on line 0
PHP Fatal error: XCache: failed init opcode cache in Unknown on line 0
[root@localhost lighttpd]# 2008-10-16 11:53:50: (mod_fastcgi.c.1743) connect failed: No such file or directory on unix:/tmp/php.socket-3
第一个是lighttpd的compress的模块，是写入文件的
第二个是XCache的临时目录写入
第三个是php的socket文件
看来是tmp目录所在的分区满了。
大体应该是lighttpd使用的压缩文件占用空间越来越大，导致空间不足，把lighttpd的compress目录重新设置到富裕的分区就好，然后把tmp目录的压缩文件目录都删掉即可。
