Tag Archives: Web

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 年的内容基本上是一致的)。

继续阅读

YATT — WebService Debug 工具

从这则 Low level debugging webservices 得知了YATT (Yet Another Trace Tool) , Trace 工具已经太多,所以,这个东西叫 Yet Another Trace Tool :).

YATT is a project to replace the current proliferation of trace tools ( tcpTrace, proxyTrace, pcapTrace ), with a single extensible tracing tool. YATT features a new GUI built with WTL, complete with a Hex View mode, and currently ships with 2 Trace providers, one based on WinPCAP and one based on the W2K Raw sockets support. Tunnelling & HTTP Proxy providers will be added in a later build.

tcpTrace, proxyTrace, pcapTrace 这三个产品也可以在 PocketSoap 站点上找到. PocketSoap 是一个专注 Web Services 的小公司。站点上还有大量的代码可供下载研究用。
YATT 只有 220 K 大小,可谓短小精悍。不光 Debug Web Services 有用,普通的 HTTP 开发也用的上。
YATT(Yet Another Trace Tool)工具示例
这个产品我以为会是开源的,但是没有找到源代码。或许是因为还在开发中的缘故吧。
EOF

DouBan vs. ZhuaXia vs. kooxoo.com

douban zhuaxia.kooxoo.com


douban zhuaxia.kooxoo.com

Originally uploaded by Fenng(dbanotes).

偶然对三这个站点作了一下比较。发现流量统计还是蛮有意思的。
1) 豆瓣的流量比较稳定。用户群体稳定。从 SEO 的角度上看, URL_rewrite 做的非常好. 整个网站几乎没有动态 URL,非常优雅。
2) 抓虾流量太低了。这应该和他们大量使用Ajax有关,此外,在用户使用主页面用了 Frame ,这是搜索引擎优化的大忌. 我在实际使用的过程中也觉得抓虾稍有点华而不实。
3) 酷迅 的流量窜升的很快. 搜索引擎还是用户最常使用的工具之一. (有意思的是,还有一个网络站点也叫做”酷迅”,在Google搜索”酷迅”该站点排在前面)。Kooxoo 再过一段时间会被更多人看好。
这三个站点是国内 Web 2.0 类的站点中非常强调技术的。相信路也会越走越远。
EOF

转载技术文章是对互联网的一种伤害

前几天看到某 BSP 上的一个所谓”博客”,把我写的一篇技术总结原封不动的转载过去,甚至下面的用户评论也不放过。这种现象在中文网络恐怕是司空见惯,很多人可能也习以为常了。
中国互联网有一种现象恐怕是老外很难看懂的,那就是网络论坛无比繁荣,甚至繁荣得泡沫四起。传递繁荣的载体之一就是”转载”(“转贴”,”ZT”,”ZZ”),对于有的内容(比如实事评论、文学作品),转贴是一件好事,平面媒体不也有什么《文摘旬刊》之类的么? 但对于技术类的文章来说,转载则是一种很有问题的传播方式。
弊端主要有如下几个:
1) 丧失了原有的格式HTML 语言标记过的内容经过简单的 CTRL+C CTRL+V ,丧失了原有的格式。这对于读者来说是一种不负责任的表现。有的文档,虽然原作者精心排版,可是在若干次拷贝粘贴后面目全非。
2) 丧失了数据准确性。技术文档可能包括实例代码、表格数据等内容,几经转载后很难认为该数据是不被篡改或是丢失,数据的可读性会给人带来一定的困惑。
3) 读者无法得到更新内容。超链接是 Web 一大基本属性。转载后的技术文档,很难保证原有的超链接仍旧存在。如果这个通道断掉。那么原作者对文章的更正、修改、补充等内容读者无从知悉。有此产生的误解、困惑谁应该负责?
4) 损伤原作者积极性。看着自己辛苦写出来的技术文章,一转眼的功夫就被人张冠李戴,任你再有涵养也要深为沮丧,几次过后也就没有了继续写作的兴趣。从 Web 页面本身来说,PageRank 也会受损,久而久之,劣币必然影响良币。
也或许,问题并不止这么几个。如果你看到一篇技术文档的确觉得不错,非常想转载,在转载之前不妨尝试如下几个步骤:
1) 收藏为书签。比如添加到 del.icio.us 或者是 365key,收藏的时候加上自己队该文章的一点评论最好不过。
2) 如果第一条不是很好转载的时候把原作者署名,并且一定要加上原文地址。别人看到这个’鸡蛋’不错,让他们直接去找生那只蛋的’母鸡’。
3) 如果还不行,问问自己这样做的目的。转载一篇很牛的文章后技术社区里的人会对你更有好感么(还是仅仅因为虚荣诱使你这样做)? 别人是否会误认为这篇文章的作者是你? 如果他们就这个问题对你提问,你能搞定么?
4) 最后一条。看过了前三条你觉得很麻烦,那么就不要转载了吧。
有的人可能是出于一种“好东西自己也要有”的心理,最喜欢用的理由是: 万一别的地方找不到了呢?
别担心, 搜索引擎会缓存互联网所有有价值的东西
EOF