偶尔开着网页监控，看看网站的信息，可以看到服务器软件名称等信息：
http://www.mop.com/
Server lighttpd
X-Cache HIT by 82
X-MEM-Hit by mem-compress
使用lighttpd作为响应服务器似乎有点不太相信，X-cache应该是加了文件缓存模块，还有mem的缓存，速度应该也不错
我也比较喜欢lighttpd，有几个原因：
1 有很详尽的监控内容，包括正在处理的请求和fastcgi的负载情况
2 做缓存占用资源比squid少
3 配置语法很灵活简洁
不好的地方是单进程，重启会中断现有连接
http://www.163.com/
Server nginx/0.7.22
Via 192.168.51.74.nginx, 1.0 cache.163.com (squid/3.0.STABLE13)
X-Cache HIT from cache.163.com
nginx作为响应服务器，后端有squid和nginx
多看了一下163的图片服务器，居然一把抓的nginx，看来这nginx真的是普及好快
我也喜欢nginx，有几个原因：
1 主进程管理，比lighttpd好，可以平缓过渡配置
2 代理可以设置主备方式，很实用
3 很简洁灵活的配置语法，部分操作比lighttpd强
http://www.sohu.com/
Server Apache/1.3.39 (Unix) mod_gzip/1.3.26.1a
Via 1.0 17376722.22226606.29245568.sohu.com:80 (squid)
X-Cache HIT from 17376722.22226606.29245568.sohu.com
squid和apache的配置
这两者我使用的不多了，squid因为资源占用问题（也许我们没配置好）而放弃
apache还是不够上面两个方便
http://www.cctv.com/
Server Apache
Vary Accept-Encoding,User-Agent
Via 1.0 ds-cache-3 (squid/3.0.STABLE10)
X-Cache HIT from ds-cache-3
X-Cache-Lookup HIT from ds-cache-3:80
X-UA-Compatible IE=EmulateIE7
squid的群，后端是apache
http://www.mop.com/
Server lighttpd
X-Cache HIT by 82
X-MEM-Hit by mem-compress
使用lighttpd作为响应服务器似乎有点不太相信，X-cache应该是加了文件缓存模块，还有mem的缓存，速度应该也不错
我也比较喜欢lighttpd，有几个原因：
1 有很详尽的监控内容，包括正在处理的请求和fastcgi的负载情况
2 做缓存占用资源比squid少
3 配置语法很灵活简洁
不好的地方是单进程，重启会中断现有连接
http://www.163.com/
Server nginx/0.7.22
Via 192.168.51.74.nginx, 1.0 cache.163.com (squid/3.0.STABLE13)
X-Cache HIT from cache.163.com
nginx作为响应服务器，后端有squid和nginx
多看了一下163的图片服务器，居然一把抓的nginx，看来这nginx真的是普及好快
我也喜欢nginx，有几个原因：
1 主进程管理，比lighttpd好，可以平缓过渡配置
2 代理可以设置主备方式，很实用
3 很简洁灵活的配置语法，部分操作比lighttpd强
http://www.sohu.com/
Server Apache/1.3.39 (Unix) mod_gzip/1.3.26.1a
Via 1.0 17376722.22226606.29245568.sohu.com:80 (squid)
X-Cache HIT from 17376722.22226606.29245568.sohu.com
squid和apache的配置
这两者我使用的不多了，squid因为资源占用问题（也许我们没配置好）而放弃
apache还是不够上面两个方便
http://www.cctv.com/
Server Apache
Vary Accept-Encoding,User-Agent
Via 1.0 ds-cache-3 (squid/3.0.STABLE10)
X-Cache HIT from ds-cache-3
X-Cache-Lookup HIT from ds-cache-3:80
X-UA-Compatible IE=EmulateIE7
squid的群，后端是apache
今日特意优化某几个服务器，发现正在使用Nginx的服务器A很能跑，跑到了慢慢的100M带宽，很令人欣慰。
（100M是一般机器租用的带宽量，跑的满了，说明你在最大的发挥了这个机器的性能，用户也达到了最大的下载速度）
于是也希望应用到另外的机器，看看都有什么不同的提升情况。
B和C用的是lighttpd，切换前使用到了仅仅40M带宽，切换后，居然能跑到了80M，也很不错的成绩了。
C也大致能跑到60-70M，但不知为何下落了，切换后至少比较稳定在70M，很好。
其实我不是lighttpd的专家，也不是说lighttpd不好，只能说我没用好，或者怎么用好它还没摸索到，也希望能有lighttpd的优化方案可以参考，我其实觉得它们两个都有很好的性能。Nginx也没有很好的配置就已经这么好了，就只是加大了worker和并发处理的量，就有很不错的表现。
但同时，使用Nginx后，负载明显增加了，大概在5左右，这个比较高，用lighttpd虽然带宽没有达到那么高，但负载比较低，也就在1左右，那估计发挥一下lighttpd的威力，达到同样的负载压力估计也能够有这样的效果吧？谁教我呢，呵呵。。
使用Nginx是有一些缺点的：
1 不支持cgi，在某些方面不便，如果需要处理，需要配置fastcgi环境
2 不支持日志的管道操作
lighttpd有个缺点：需要kill了才能重新启动，这个很不好，当然，可能我没有找到好的解决方案，或者我不知道。
采集也做负载均衡，那样可以做的更加稳定和快速。
今天发现某采集功能（采集A服务器的内容）占用时间特别长，很多进程呆滞着了。检查是在该机器上访问A服务器比较慢，在别的机器上访问A服务器还是比较快的，看来可以考虑做一个备用方案，访问A服务器很慢的时候可以考虑用别的机器访问。
如果在程序上修改，那活动性很差，所以尽量还是要保证程序的不变，让这个机器上访问一个网址还有负载均衡，那只能访问一个负载均衡的服务器中间服务器了。
加上是 B服务器要访问 A的内容，B的服务器可以访问C服务器，让C服务器做代理功能，那就可以做代理的负载均衡了，就可以把任务分散到DEF等机器了。
流程：A -> C -> DEF -> B
就大概变成这个流程了，当然，AC是可以是一台机器，甚至C也可以作为负载均衡的其中一个。
假设我要访问B服务器 1.2.3.4 域名是 www.aslibra.com
我有 CDEF 是 192.168.1.2/3/4/5
那A上加上hosts文件设定，这样在访问的时候就无形了
今天发现某采集功能（采集A服务器的内容）占用时间特别长，很多进程呆滞着了。检查是在该机器上访问A服务器比较慢，在别的机器上访问A服务器还是比较快的，看来可以考虑做一个备用方案，访问A服务器很慢的时候可以考虑用别的机器访问。
如果在程序上修改，那活动性很差，所以尽量还是要保证程序的不变，让这个机器上访问一个网址还有负载均衡，那只能访问一个负载均衡的服务器中间服务器了。
加上是 B服务器要访问 A的内容，B的服务器可以访问C服务器，让C服务器做代理功能，那就可以做代理的负载均衡了，就可以把任务分散到DEF等机器了。
流程：A -> C -> DEF -> B
就大概变成这个流程了，当然，AC是可以是一台机器，甚至C也可以作为负载均衡的其中一个。
假设我要访问B服务器 1.2.3.4 域名是 www.aslibra.com
我有 CDEF 是 192.168.1.2/3/4/5
那A上加上hosts文件设定，这样在访问的时候就无形了
192.168.1.2 www.aslibra.com
cacti在服务器监控方面有很广的使用，也简单方便。
在网上也很久之前看过安装介绍，但之前尝试过安装，在rrdtool的安装过程就有点失败就没有做，看了《你还在用mrtg吗?－－使用cacti监测系统性能》一文，得知安装旧版本的rrdtool可以不用安装那么多的插件：
上文说的也不错，但对于已经有相关的环境的服务器来说，就不用那么复杂，我也来一个笔记。
首先我们了解一下cacti的必须工具和软件：
1 rrdtool，用来画图用的工具，方便从数据做出相关图形
2 php，运行php用的了，不用说了
3 web服务器，不需要是apache，支持php就可以了
4 mysql，cacti使用的数据库
5 snmp相关工具，获取监控设备的信息用的
mysql很容易处理，使用现成的数据库就可以，能执行sql语句导入并且有相应权限即可
支持php的web服务器就可以，apache+php模块、lighttpd+php-fastcgi等配合都可以
一般来说，会缺少rrdtool和snmp工具。
引用
cacti在英文中的意思是仙人掌的意思，但在开源世界里它还有另外一层意思---NOC监控软件，而且除了本身的强大功能外，它还能安装众多插件来实现拓展，在国内很多地方可能还在使用昂贵的NOC软件进行监控的时候，cacti的爱好者们已经可以非常惬意的休息了。
在网上也很久之前看过安装介绍，但之前尝试过安装，在rrdtool的安装过程就有点失败就没有做，看了《你还在用mrtg吗?－－使用cacti监测系统性能》一文，得知安装旧版本的rrdtool可以不用安装那么多的插件：
引用
安装rrdtool
下载：
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/rrdtool-1.0.x/rrdtool-1.0.50.tar.gz
然后
./configure
make && make install
与mrtg相比,rrdtool自带了gd库,所以不用先安装gd库.(不过由于rrdtool自带的gd库不支持中文,所以rrdtool画出来的图也不能有中文,否则会出现乱码).
注 意：rrdtool1.2的版本由于已经不再自带外部的lib库（如cgilib，zlib等），所以需要 从http: //people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/libs/下载这些库来安装。建议还是使用 1.0的版本，比较方便。
下载：
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/rrdtool-1.0.x/rrdtool-1.0.50.tar.gz
然后
./configure
make && make install
与mrtg相比,rrdtool自带了gd库,所以不用先安装gd库.(不过由于rrdtool自带的gd库不支持中文,所以rrdtool画出来的图也不能有中文,否则会出现乱码).
注 意：rrdtool1.2的版本由于已经不再自带外部的lib库（如cgilib，zlib等），所以需要 从http: //people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/libs/下载这些库来安装。建议还是使用 1.0的版本，比较方便。
上文说的也不错，但对于已经有相关的环境的服务器来说，就不用那么复杂，我也来一个笔记。
首先我们了解一下cacti的必须工具和软件：
1 rrdtool，用来画图用的工具，方便从数据做出相关图形
2 php，运行php用的了，不用说了
3 web服务器，不需要是apache，支持php就可以了
4 mysql，cacti使用的数据库
5 snmp相关工具，获取监控设备的信息用的
mysql很容易处理，使用现成的数据库就可以，能执行sql语句导入并且有相应权限即可
支持php的web服务器就可以，apache+php模块、lighttpd+php-fastcgi等配合都可以
一般来说，会缺少rrdtool和snmp工具。
Fastcgi是服务器动态内容和静态内容分离的很好的方法，也可以方便做负载均衡，相关介绍可以看看：
1 《php-fpm文档中文翻译》
2 《用NFS和fastcgi来分担服务器压力》
以下资料的原文请参考《Optimizing FastCGI performance》，本人不是完整翻译，仅总结一些我的使用情况，必要会引用一下原文。
最近如果你经常碰到这样的问题，那你可以看看本资料：
1 我的负载均衡是否配置合适，该设置多少个进程？
2 为什么我会经常碰到500的错误？
到底多少个PHP进程比较合适？
基本算法：假设你的服务器一秒有100个PHP请求，每个处理0.1秒就完毕，那你的负载就大约在100*0.1=10，也就是10个进程就可以了，具体看你的网站情况。
1 《php-fpm文档中文翻译》
引用
FastCGI是一个可伸缩的，高速地在web server和脚本语言间交互的接口。关于FastCGI技术的更多信息可以在官方网站和这里看到。
多数流行的web server都支持FastCGI。包括Apache(mod_fastcgi和mod_fcgid)，Zeus，nginx和lighttpd。
FastCGI的主要优点是把动态语言和web server分离开来。这种技术允许把web server和动态语言运行在不同的主机上，以大规模扩展和改进安全性而不损失生产效率。
php-fpm可以和任何支持远端FastCGI的web server工作。
多数流行的web server都支持FastCGI。包括Apache(mod_fastcgi和mod_fcgid)，Zeus，nginx和lighttpd。
FastCGI的主要优点是把动态语言和web server分离开来。这种技术允许把web server和动态语言运行在不同的主机上，以大规模扩展和改进安全性而不损失生产效率。
php-fpm可以和任何支持远端FastCGI的web server工作。
2 《用NFS和fastcgi来分担服务器压力》
以下资料的原文请参考《Optimizing FastCGI performance》，本人不是完整翻译，仅总结一些我的使用情况，必要会引用一下原文。
最近如果你经常碰到这样的问题，那你可以看看本资料：
1 我的负载均衡是否配置合适，该设置多少个进程？
2 为什么我会经常碰到500的错误？
到底多少个PHP进程比较合适？
基本算法：假设你的服务器一秒有100个PHP请求，每个处理0.1秒就完毕，那你的负载就大约在100*0.1=10，也就是10个进程就可以了，具体看你的网站情况。
网上有专门的调查分析（200809）：
[没有表格化，看看数据就好了]
Vendor Product Web Sites
Apache Apache 91,068,713
Microsoft IIS 62,364,634
Google GFE 10,072,687
Unknown Unknown 3,835,616
lighttpd lighttpd 3,095,928
nginx nginx 2,562,554
[没有表格化，看看数据就好了]
Vendor Product Web Sites
Apache Apache 91,068,713
Microsoft IIS 62,364,634
Google GFE 10,072,687
Unknown Unknown 3,835,616
lighttpd lighttpd 3,095,928
nginx nginx 2,562,554
CGI文件的输出控制：
输出两个expires头，最大有效时间的生效
输出两个Cache-Control头，no-cache可生效
输出两个Cache-Control的max-age，时间长的生效，跟先后没有关系
#echo "Expires: Mon, 26 Jul 1997 05:00:00 GMT"
#echo "Cache-Control: no-cache, must-revalidate"
#echo "Cache-Control: max-age=200"
#echo "Pragma: no-cache"
#echo "Cache-Control: no-cache, must-revalidate"
#echo "Cache-Control: max-age=200"
#echo "Pragma: no-cache"
引用
[root@gx ~]# curl -I http://pic.aslibra.com/cgi-bin/test1.cgi
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:04:19 GMT
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: max-age=120
Location: http://test.aslibra.com/cgi-bin/test1.cgi
Date: Sat, 20 Sep 2008 12:02:19 GMT
Server: lighttpd/1.4.15
Age: 6
X-Cache: HIT from No1.proxy
Connection: close
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:04:19 GMT
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: max-age=120
Location: http://test.aslibra.com/cgi-bin/test1.cgi
Date: Sat, 20 Sep 2008 12:02:19 GMT
Server: lighttpd/1.4.15
Age: 6
X-Cache: HIT from No1.proxy
Connection: close
输出两个expires头，最大有效时间的生效
引用
[root@gx ~]# curl -I http://pic.aslibra.com/cgi-bin/test1.cgi?
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:07:29 GMT
Cache-Control: max-age=120
Cache-Control: no-cache, must-revalidate
Location: http://test.aslibra.com/cgi-bin/test1.cgi?
Date: Sat, 20 Sep 2008 12:05:29 GMT
Server: lighttpd/1.4.15
X-Cache: MISS from No1.proxy
Connection: close
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:07:29 GMT
Cache-Control: max-age=120
Cache-Control: no-cache, must-revalidate
Location: http://test.aslibra.com/cgi-bin/test1.cgi?
Date: Sat, 20 Sep 2008 12:05:29 GMT
Server: lighttpd/1.4.15
X-Cache: MISS from No1.proxy
Connection: close
输出两个Cache-Control头，no-cache可生效
引用
[root@gx ~]# curl -I http://pic.aslibra.com/cgi-bin/test1.cgi?1
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:08:38 GMT
Cache-Control: max-age=120
Cache-Control: max-age=10
Location: http://test.aslibra.com/cgi-bin/test1.cgi?1
Date: Sat, 20 Sep 2008 12:06:38 GMT
Server: lighttpd/1.4.15
Age: 13
X-Cache: HIT from No1.proxy
Connection: close
[root@gx ~]# curl -I http://pic.aslibra.com/cgi-bin/test1.cgi?6
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:38:25 GMT
Cache-Control: max-age=120
Cache-Control: max-age=200
Location: http://test.aslibra.com/cgi-bin/test1.cgi?6
Date: Sat, 20 Sep 2008 12:36:25 GMT
Server: lighttpd/1.4.15
Age: 122
X-Cache: HIT from No1.proxy
Connection: close
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:08:38 GMT
Cache-Control: max-age=120
Cache-Control: max-age=10
Location: http://test.aslibra.com/cgi-bin/test1.cgi?1
Date: Sat, 20 Sep 2008 12:06:38 GMT
Server: lighttpd/1.4.15
Age: 13
X-Cache: HIT from No1.proxy
Connection: close
[root@gx ~]# curl -I http://pic.aslibra.com/cgi-bin/test1.cgi?6
HTTP/1.0 302 Moved Temporarily
Expires: Sat, 20 Sep 2008 12:38:25 GMT
Cache-Control: max-age=120
Cache-Control: max-age=200
Location: http://test.aslibra.com/cgi-bin/test1.cgi?6
Date: Sat, 20 Sep 2008 12:36:25 GMT
Server: lighttpd/1.4.15
Age: 122
X-Cache: HIT from No1.proxy
Connection: close
输出两个Cache-Control的max-age，时间长的生效，跟先后没有关系
