Tag Archives: lighttpd

Lighttpd 的 spawn-fcgi 成为独立项目

收到邮件说 Spawn-fcgi 成为独立项目，并且预发布了 1.6 版本。

原来很多人都用 Lighttpd 的 Spawn-fcgi 进行 FastCGI 模式下的管理工作，不过有不少缺点。而 PHP-fpm 的出现多少缓解了一些问题，但 PHP-fpm 有个缺点就是要重新编译，这对于一些已经运行的环境可能有不小的风险(refer)。

原来 spawn-fcgi 版本也比较乱的，期待独立后的项目能更稳定一些。这会给很多 Web 站点带来便利。

–EOF–

豆瓣的 Web 服务器

豆瓣最近发布新功能有些”疯狂”，所以服务器也有新的部署。看到阿北同学在豆瓣广播里说：

豆瓣的第二台应用服务器终于投入了使用。Hongqn 忙了一晚上就完成了部署。第一台服务器支撑到 500 万动态PV/天，服务 On Demand 即时分布式部署......

500 万 PV , 还是动态 PV, 是个很惊人的数字。因为，如果都能达到一台机器支撑 500 万，那么国内稍有点规模的网站(就说动态 PV 上亿的吧)，只需要 20 台 Web 服务器就够了。事实上，即使比较强调技术的网站怕也要上百台 Web 服务器的规模。

我们知道豆瓣用 Lighttpd 做 Web 服务器。 从侦测到的数据看，目前线上有两个版本。

$ curl -I http://www.douban.com
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.15

另外一个版本：

$ curl -I http://www.douban.com/people/ahbei/
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.18

其实豆瓣服务器还有个更为惊人的性能数字。从这个 Powered by Lighttpd 的列表来看，豆瓣在一台 Gentoo 服务器上的记录是 1200 万/天的点击量。这应该是动、静态页面混合情况下的吧。

有同事对这个数据有些好奇，问我到底豆瓣是用啥做的服务器，其实这个问题我也问过阿北，他们就是自己攒的 PC 服务器，然后把性能发挥到极致。阿北也表示过，即使现在豆瓣流量激增个十倍啥的性能也不会是问题。这也是从起始就考虑扩展性的收益吧。

这里这位老兄用 七个 Mongrels 实例(也是一台Server)跑了 55 万 PV (thanks Robin 纠正) 就蛮自豪的，所以豆瓣的一台跑了”500 万动态 PV” 的确非常惊人。

Updated 2008-1-17 0:57:09

阿北留言了。主要是上面的有的数据还是旧的:

Lighty 网站上的数字很久没有去更新了。现在豆瓣的web服务器(lighttpd)每天估计2500万 Hits, 高峰时间大约1000 req/s (这里说的是主要输出HTML/CSS/JS和小图片的一台前端。大图片有另外的web服务器)。
我在广播里说500万PV/天的是应用服务器，就是lighty和mysql之间跑python的那台。现在豆瓣大多数PV来自注册用户，每个页面都需要几到十几种类的动态数据。
现在的服务器只是单片双核的opteron。换4核的话，应该能到一台1000万PV/ 天。

友情提醒，留言很精彩，敬请查看。不过在这个 Blog 上留言的确用户体验很糟糕(我也很烦),相信本周末能得到解决。

–EOF–

WikiPedia 技术架构学习分享

维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。

来点直接的数据：

  • 峰值每秒钟3万个 HTTP 请求
  • 每秒钟 3Gbit 流量, 近乎375MB
  • 350 台 PC 服务器

    • (数据来源)

架构示意图如下：
WikiPedia_arch.png Copy @Mark Bergsma

GeoDNS

在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? “A 40-line patch for BIND to add geographical filters support to the existent views in BIND”, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的–面向各个国家，各个地域。

负载均衡：LVS

WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.

图片服务器:Lighttpd

Lighttpd 现在成了准标准图片服务器配置了。不多说。

Wiki 软件: MediaWiki

对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。

Cache! Cache! Cache!

维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。

数据库: MySQL

MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离……应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。

参考文档：

Wikimedia architecture （PDF)
Todd Hoff 的文章

–EOF–

WordPress 对 Gravatar 进行的优化

WordPress.com 母公司 Automattic刚收购 Gravatar 没几天，工程师就对 Gravatar 进行了一番手术，把 Gravatar 并入了 WordPress.com 的技术架构.

合并后的 Gravatar 在两个不同的数据中心各有一台应用服务器 + 1 台 Cache 服务器。Cache 服务器用的软件是 Varnish ，峰值能够处理 1000个/秒 的请求，效率很惊人，据说 Varnish 跑在 FreeBSD 6 或是Linux 2.6 上充分发挥性能，实际处理能力比这个还要强。

Web 服务器分两种：普通的为 Apache2 + Mongrel, 图片服务器则是 lighttpd + mod_magnet (看来 lighttpd 是图片服务器非常流行的使用啦 )，不过他们遇到了内存泄漏问题(Bug?)，每隔一段时间要重新启动一次，对这个的控制用的是 Monit

Monit 这个小工具我是第一次知道，功能也很有趣。

小成本，高性能，这帮老外玩的就是透。国内的 Feedsky 啥的也需要加把劲儿了，最起码也要向豆瓣看齐吧?

–EOF–