Tag Archives: Apache

《Apache源代码全景分析》

上半年好像我写了不少推荐序。《Apache源代码全景分析第1卷》已经面市一段时间了。读过这本书的电子稿，先睹为快之后写下推荐序。

如果说没有 Apache 就没有 Internet 可能有些夸张，但至少可以说没有 Apache ，互联网不会发展这么快。根据互联网研究公司 NetCraft 的统计，多年来 Apache 一直是稳居 Web 服务器市场头把交椅，至今仍占据超过 50% 的市场份额。就整个互联网来说，Apache 仍然是最重要的软件之一。

Apache_Source_Code.jpg

尽管近几年来涌现出不少以”高性能”为卖点的新的 Web 服务器软件，比如 Lighttpd 、Nginx 等，吸引了不少用户注意力，不过 Apache 因其功能广泛，有些仍具有不可替代性，在技术领域仍然是 Web 服务器风向标。话说回来，”重剑无锋，大巧不工”，有的时候软件性能表现不佳，更多原因可能是对其了解不够、使用不当造成，并非软件自身有多大缺陷。 对 Apache 来说，更是如此。所以，通过分析源代码了解 Apache 软件架构体系，熟知其本质，方能更有效的使用 Apache Web 服务器，从而发挥出最大效能。为网站节省资源，为企业节省资金，也能为用户提供更好的访问体验，好处多多。

此外，随着互联网业务的复杂化，很多网站使用 Apache 的过程中也遇到了新的挑战，常常要在业务的驱动下对 Apache 进行扩展性的开发(例如扩展日志模块以便于更复杂的日志统计)。这个时候，源代码分析是绕不过去的一件事儿，尽管源代码获取是轻而易举之事，但 Apache 代码毕竟凝聚了开源软件界的群体智慧，要想高效分析却是并非易事，相信这本书能让有此需求的读者少走弯路，剥丝抽茧，获得更多启发与借鉴。

说起源代码分析，其实几年前市面上出现过一些此类话题的图书，不过基本上是印上大段源代码加上几句注释了事，读者可能会有吃到注水猪肉的感觉。而本书的读者对这一点大可放心，书中代码只是点到即止，相对环保多了。

后记：此书编辑够用心的，这里这个案例可见一斑。

–EOF–

Nginx 的推广问题

偶然发现 Nginx 稳定版本更新到了 0.6.31，这个版本修正的第一个 Bug 值得注意：

Nginx did not process FastCGI response if header was at the end of FastCGI record

现在国内 Nginx 的用户越来越多了，多数拥抱 Nginx 的网站都钟意其优异的性能表现，如果是相对比较大的网站，节约下来的服务器成本无疑是客观的。而有些小型网站往往服务器不多，如果采用 Apache 这类传统 Web 服务器，似乎也还能撑过去。但个人觉得有其很明显的弊端： Apache 在处理流量爆发的时候(比如爬虫或者是 Digg 效应) 很容易过载，这样的情况下采用 Nginx 不失为大胆而有效的尝试。

当前 Ngnix 美中不足之处是相关的文档和用户经验都还是很欠缺，用户之间还很难做到可借鉴性的交流。

最近因为朋友遇到一些技术问题，我也翻阅了不少 Nginx 的邮件列表内容，发现大量的技术细节仍然在频繁变化中，可是中文社区内相关的记录和讨论太少了。相信国内这些 Nginx 用户积攒的经验肯定是不少的，但可能是因为某些其它因素考虑而看不到相关的技术分享。

当期待大家都做某件事情的时候，最好从自己做起。现在开始尝试收集 Nginx 的相关技术细节……

–EOF–

小发现，网易新闻用的是 nginx/0.5.36

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Google 站内 URL 地址处理的有趣现象

一直误以为 Google 的 URL 地址是大小写不敏感的。偶然间发现：
https://www.google.com/adsense (可以访问)
https://www.google.com/adSense (http 404 错误)
看来不是。继续测试一下其他地址：
http://www.google.com/intl/zh-CN/options/ (可以访问, 中文)
http://www.google.com/intl/zh-cn/options/ (可以访问, 英文)
http://www.google.com/intl/ZH-CN/options/ (可以访问, 英文)
http://www.google.com/iNtl/zh-CN/options/ (不可访问, 404 错误)
Apache 的 mod_speling 如果启用的话，并且 httpd.conf 文件 配置了

CheckSpelling on

的话，Apache 则大小写不敏感。但这样性能会很差。
也或许，Google 这样做就是为了追求更好的性能而没有使用类似的模块(Google 当然没那么简单)或者其他处理，毕竟 Google 整个站点的入口页面并不是那么多。
Updated: 雅虎的站内地址几乎都是大小写不敏感的. 下面两个地址等价：
http://sports.yahoo.com/MLB/scoreboard
http://sports.yahoo.com/mlb/scoreboard
Yapache 还是有技术含量地。
–EOF–

Yapache-Yahoo! Apache 的秘密

作为世界上 NO.1 的 Web 站点，Yahoo! 的 Web 服务器定有独到之处. 这也应该是很多 Web 技术人员关心的一个问题。
前一段时间, Yahoo! 架构软件组的技术经理 Michael J. Radwin 在 OSCON 2006 上作了一个题目为 Hacking Apache HTTP Server at Yahoo! 的报告，透露了很多关于 Yahoo! Apache 的技术信息。
Yahoo! Apache = Yapache , 这是雅虎内部使用的名字吧。发音是(why·apache)(注：根据下面的留言，读音应为[ya`pache])。 YApache 是基于 Apache 1.3 进行 hack 的，目前在向 Apache 2.2 迁移(Prefork Multi-Processing Module ?)。 Michael 介绍说构建 YApache 的原因有三个：
1) 安全性;
2) 节省带宽;
3) NETSCAPE GUIDE BY YAHOO–这是 97 年的时候 Yahoo! 与 Netscape 联合推出的 一个互联网信息与导航服务，需要用到富媒体内容，当时的 Apache 对这样的内容支持较弱，所以雅虎不得不动手改造 Apache (要知道97 年的时候 Netscape 就好比现在的 Google 啊)。据说这才是主要原因。
Apache 1.3 的功能对雅虎来说已经够用 (在 98 年对 yapache 添加了 gzip 的支持)，所以这个版本一致用到现在。YApache 的一个倾向性的原则是用进程而不用线程，相对比较保守，不过这样选择的原因也是很明显的：进程更加稳定，线程对与程序员来说，更容易引入新的问题。
接下来 PPT 描述了一些关于 LOG 格式的内容，继续看下去，我感兴趣的是关于配置参数 StartServers / MaxSpareServers / MinSpareServers / MaxClients 的问题。很多 Web 技术人员往往要在这个地方反复推敲。YApache 一般只设置 MaxClients，这个值一般小于 100, 对于 99% 的站点是足够用了。尽量让系统(Yahoo! BSD) Kernel 来处理 Buffer， 在这个地方关于 几个 kernel 参数的设置很有讲究。
关于SSL 的部分我不太感兴趣，倒是最后的 ysar (Yahoo! sar) 看起来是一个有趣的工具.
这样的定制对于 Yahoo! 这样需要大量 Web 服务器的站点来说(现在平均每天接近 40 亿 的 PV)，得到的收益无疑是巨大的。对于规模相对较小的 Web 2.0 站点，类似 LightTPD 这样的轻量级 Web 服务器更为适合(比如豆瓣):

$ curl -I www.douban.com
HTTP/1.1 200 OK
Connection: close
Status: 200 OK
Content-Length: 13213
Content-Type: text/html; charset=utf-8
Set-Cookie: dbcl2="MPmAySb0OYE::"; path=/; domain=douban.com; \
expires=Thu, 01-Jan-2009 00:00:00 GMT
Date: Fri, 22 Sep 2006 12:34:16 GMT
Expires: -1
Server: lighttpd/1.4.11

(那些盯着豆瓣页面看的模仿者，很少有人留心豆瓣的运维技术吧)
在线查看这个PPT： Hacking Apache HTTP Server at Yahoo! (PDF Version) (其实这个文档和 05 年的内容基本上是一致的)。

继续阅读 →