分类 Network 下的文章

总结一下lighttpd的优缺点

今天实在没得可写,不如炒个冷饭,以前发在论坛的帖子

优点

发信人: kxn (一整夜), 信区: NewSoftClub
标 题: Re: eaccelerator可以用在apache+php+fastcgi中吗?
发信站: 水木社区 (Sat Feb 11 11:19:26 2006), 站内

内存占用非常之少,可以节省下来大量内存给应用和磁盘缓存。此外单进程减少很多不必
要的 context switch , 在慢网并发连接时候非常明显了。

当然最明显的好处是比其他各色诡异 httpd 从功能上面更接近 apache, 迁移成本相对低
一些。cgi/fcgi, rewrite, access, expire 这几个常见 module 都有,

虚机的配置处理方式比 apache 直观很多,我一直觉得 apache 的虚机配置格式实在是很失
败的一个设计,一不小心请求就进错虚机了,调起来很郁闷, lig 的 url 和虚机处理格式
是统一的,很适合用来作统一入口。

缺点

发信人: kxn (一整夜), 信区: NewSoftClub
标 题: Re: eaccelerator可以用在apache+php+fastcgi中吗?
发信站: 水木社区 (Sat Feb 11 10:09:31 2006), 站内

我也来说一下 lighttpd 的缺点吧,先打个预防针

1: 不支持 scriptalias , 对于一大目录 cgi 的应用(比如某邮件系统),非常难弄,有
个变通方法可以凑合用,但是要求所有 cgi 都是 binary 的,不能是脚本

2: 没有 mod_caucho/mod_jk ,带 resin 之类的只能用 mod_proxy, 但是 mod_proxy 过
去了就没有对方 IP 了,只能自己从 X-Forwarded-For 里面截,要改应用。

3: 经常有些小 bug 需要自己读代码找原因,比如 mod_proxy 对 3xx 的重定向请求处理有
点问题,对1.4.8 的 mod_dirlisting 中文乱码等, apache 是基本这些小 bug 都被别人
踩的差不多了

我基本就遇到这几个,不过相信应该还有不少。。

【 在 hBifTs (Programing?Reverse:Crack…) 的大作中提到: 】
: good….把apache换成lighttpd…

将 lighttpd 进行到底, mod_proxy 对一些请求不返回应答 body 的解决方法.

1.4.10 这么快就出来了,号称里面修正了 mod_proxy 处理 30x 请求时候返回 body 不正常的问题, 不过升级了一下发现还是有问题,仔细看了一下,原来本身就是只修正了 301 这一种请求,  而某系统会发送 305 带 body  的结果,于是就不好用了. 自己简单改了一下让他可以支持该系统. 不过 lighttpd 这么干不是个事情啊. 今天搞了 305, 明天说不定还会有不规范的应用用 306,  为啥就一定这么抠门,一点body 都舍不得发回去哪?

改法:

src/connections.c 第 463 行加上

 305 :

LVS 直接路由方式简单配置,以及响应时间抖动情况

最近发现 F5 这样的负载均衡设备可能请求时间会出现抖动现象,最长的请求经常可以达到好几秒。考虑到 F5 会对所有数据进行 NAT ,有可能处理能力不足,打算研究一下 LVS 会不会有类似现象。

小知识:什么是 LVS?

LVS 是 Linux Virtual Server 的缩写,是章文嵩主持开发的基于 Linux 的类似 F5 这样的连接管理软件,它将接收到的数据包进行部分修改后,发送给后端多台服务器,实现了多台服务器共享同一个 IP 的效果,通过一些配套的 HA 软件互相监测,可以自动剔除失败的后端结点,或者启动备份的前端转发系统。为了避免所有数据都经过前端转发结点造成瓶颈,LVS 在类似  F5 那样的 NAT 模式之上,还提供了隧道模式和直接路由模式两种配置方式,后两种方式巧妙的利用了 Linux kernel 的路由处理逻辑和交换机的工作原理,使得只有入流量经过转发结点,出流量直接从后端处理结点返回给用户。一般 WWW  服务都是出流量远大于入流量,这种情况下面 LVS 可以获得很好的性能。

LVS 的直接路由模式配置:

LVS 直接路由模式是性能最好的一种方式,他的工作原理是这样的,  服务入口 IP 配置在转发结点上面,这样入流量都会被交换机送到转发结点上面,转发结点上面 LVS 模块会处理入流量数据,跟踪其中的TCP连接,将这些 TCP  连接数据分发到多台后端上面,后端的 Linux 系统在自己的lo设备上面也绑定服务入口 IP ,并打开 IP 转发,最后还要加一条路由,将服务入口 IP 指向 lo 设备上面,从前端发送过来的数据被后端收到以后,后端机器按照路由转发数据, 数据就被转发到 lo 设备上面,因为 lo 设备绑定了服务入口 IP, 这些数据就被后端机器的协议栈捡起来了。后端机器处理完数据以后,将数据发送到外网路由器上面直接发送回客户端。

从以上过程可以看出来,LVS 的直接路由模式有这些特点:

1: 前端处理逻辑比起 NAT 模式来要简单一些,只需要跟踪连接,并修改 mac 就可以。

2: 依赖于后端操作系统的路由功能,

3: 后端机器要和前端机器处于同一局域网内,否则前端无法通过不修改网络层数据来将数据发送给后端。

LVS 的简单配置方法,假设公共服务 IP 是 10.0.0.10, 前端机器是  10.0.0.11, 后端机器是 10.0.0.12-14, 前端机器上面已经安装了 ipvsadm 包,内核也已经编译支持 LVS, 配置方法如下:

# 打开前端机器的 ip_forward , 这个是 LVS 需要的
echo 1 > /proc/sys/net/ipv4/ip_forward
# 添加一个位于公网 IP 80 端口的虚拟服务, 负载均衡协议是 weighted lease connection
ipvsadm -A -t 10.0.0.10:80 -s wlc
# 添加后端 IP 们, -g 表明使用的是 direct routing 模式
ipvsadm -a -t 10.0.0.10:80 -r 10.0.0.12 -g
ipvsadm -a -t 10.0.0.10:80 -r 10.0.0.13 -g
ipvsadm -a -t 10.0.0.10:80 -r 10.0.0.14 -g

后端机器上面

# 打开 ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
# 防止后端机器应答虚拟 IP 的 arp 信息
echo ‘2’ > /proc/sys/net/ipv4/conf/lo/arp_announce
echo ‘1’ > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo ‘2’ > /proc/sys/net/ipv4/conf/all/arp_announce
echo ‘1’ > /proc/sys/net/ipv4/conf/all/arp_ignore

# 在 lo:0 上面配置虚拟 IP
ifconfig lo:0 10.0.0.10 netmask 255.255.255.255
# 增加到 lo:0 的路由
route add -host 10.0.0.10 dev lo:0
如此 LVS 应该就工作正常了,可惜用 ab 的测试结果并不是非常好,后端用 squid 来做服务,用相同的压力压在单台 squid 上面一点都没有抖动现象,通过 LVS 打,马上就能看出来抖动。sigh

lighttpd 升级了,顺便跟一下

最新的是 1.4.9

比较好的一个事情是 1.4.8 带来的 mod_dirlisting 的中文乱码问题又修正了,省得我打 patch 了,赞一个。

另外一个比较不错的功能是 mod_evasive, 可以限制同一 IP 的连接数,当然本站暂时不需要它。hehe

被Squid的统计数据骗了。。

这年头真是连胡萝卜都不可以相信。

前一段时间用了很多很多的时间和精力奋斗 squid,  当时无论怎么调整参数,  Linux 下面的 squid 性能就是比不上 FreeBSD 系统的。同样的硬件配置,DNS Round Robin 轮转均衡,Linux 的 squid 无论 hit rate 还是 traffic 都比 FreeBSD 的低一些,随着流量增加,差别还越来越明显。今天差距居然达到 33% 了,Linux 报告 traffic 在 3MB 左右,同时 FreeBSD 报告已经上 4MB 了。本来就打算得出结论,FreeBSD 作 Squid 确实有天然优势,没有想到,这只是一场骗局。。

zsg 今天察看了一下这些 squid 对应交换机网口的流量,结果发现基本是一样的,而且 Linux 那个比 FreeBSD 的还稍微高一点点。和 Squid 自己的 SNMP 数据比较,确定 Linux 的数据基本是准确的,而 FreeBSD 虚报了 33% 还多!真是!·#¥%……

造成这个现象的原因猜测是 FreeBSD 和 Linux 两者之一的计时时钟不够精确,导致计算不准确,但是为什么 Hit rate 也能高呢?这就不清楚了,确实比较奇怪,不过交换机数据和 FreeBSD 报告的差别很大也是铁板钉钉的事实,所以只能自己认为,时钟不准确,导致其他逻辑都混乱了罢。。。再怎么说,交换机出现单个口统计结果不准的可能性,也要远小于不同机器上面 Squid 报告不准的可能性吧。

总的来说,以后不能太相信程序自己报告的结果,如果有手段,还是多参考一些更公正的数据来源更有意义。
感谢 zsg 灵感去看交换机数据,解决了这个多天来的悬案。

最近评论

时光机

其他