Entries tagged with “Web” from DBA notes

接上一篇《容量规划》，谈一下流程规范这个话题。

流程规范

对于相对正规的网站维护工作，所有网站的所有变更必须能做到有记录，可回溯。如果是单枪匹马作战，那么要实现这个目标并不是很难，只需要把好习惯培养起来就成了，可如果要面对一个团队，那么就必须要依赖流程规范来进行约束。

所谓"流程规范"，在初期也可以拆开来对待：流程 + 规范(废话!)。

关于流程(Process)，直白的说就是"把大象放入冰箱需要几步?"的问题。比如上线一台服务器，那么可能要经过至少前期的选型规划、基准测试、压力测试......等等诸多步骤。如果跳过某个环节(比如缺少基准测试)而直接上线，遇到问题的时候几乎就会因为缺乏对比数据而走弯路。

关于规范(Norm)，在运维的过程中是个范围比较大的话题，因为 Web 站点环境因为各种原因而不可复制，在另一个公司可用的规范照搬到另外一家公司未必管用。如果能够意识到并且尽早抽象出来标准化组件，并着手推进，那么规范必然会逐渐丰富起来并完善。比如 Web 服务器配置规范、Linux 主机配置规范、SAN 存储系统测试规范，都是可以尽早抽象出来并且可具体化的东西。

流程规范建立容易，但是如何确保执行却是一个很有挑战性的问题。从这一点来说，对于运维团队的领导的要求还是比较高的。如果要成功管理一个运维团队，起码要有足够的技术经验(当然，也容易看到外行领导内行的运维团队)，而且要有足够强的执行力。

在流程规范的建立过程中，往往容易陷入为了规范而规范的误区，或是生搬硬套 ITIL(Information Technology Infrastructure Library，"信息技术基础架构库") 那一套大而无当的东西进来(这里不是说 ITIL 不好，但最合适自己的才是最好的)，必须明确，规范的最终目的是为了运维团队更快而不是变成束缚，所以，千万要避免技术人员对规范的抵触。

在运维团队发展的某个阶段，推行"流程规范"所引入的 ITIL 等事物是一把双刃剑，运用得当会很好的促进团队成长，运用不好则会阻碍一部分激进成员的积极性，这一点需要注意。

补充一点，对于流程规范，不是死的东西，必须具备不断反馈、改进、进化的能力，运维团队也应该定期修正流程规范的有关内容。有一句耳熟能详的话是：遵守流程而不拘泥于流程，这里的"不拘泥"切不可变成钻空子的借口，要知道我们生活中很多无形成本就是钻空子引起的。

未完待续，下一部分谈一下关于《知识管理与知识积累》等方面的内容。

--EOF--

强烈推荐一篇相关文章 运维的工序流程. Hutuworm 的大作。

接上一篇《网站运维之道 监控与报警机制》，谈谈关于容量规划。

容量规划

有效的监控能够避免绝大多数问题的扩大化，但是还是做不到防患于未然。监控告警机制完善后，就需要着手考虑容量规划(Capacity Planning)的问题。

所谓的容量规划，也就是一个公司为了满足商业目标的需求而决定生产能力的过程。俗语说，"人无远虑，必有近忧"，容量规划，需要的是"远虑"。对应到运维的工作上来，一方面是商业目标带来的容量需求，一方面是针对相关历史数据的分析带来的预测。这里的历史数据，是需要运维团队采集、整理的。(从这个角度上说)，容量规划是一个长期的过程。

相关的数据保存和图表生成，基本上都会采用 RRDtool （http://oss.oetiker.ch/rrdtool/）来做。 RRDtool 也已经是业界的事实上的标准，但毕竟 RRDtool 只能算是一套引擎。而规模化的数据管理工作则需要求助其它工具，则不能不提 Cacti （http://www.cacti.net/）这是现在相当通用的做法。老牌的 MRTG 已经很少有人用了。

利用 Cacti，很容易得到一段时间内某项数据指标的变化趋势(比如网络流量的增长趋势、服务器负载的趋势等)。这是运维过程中最主要的参考数据之一，缺乏此类数据而做决策是不可想象的。

如上图，可以发现被监控的服务器上进程数量半年内的增长趋势，在 2 月份间的进程数并不高(春节期间)，随后的几个月突破 4000 个进程，对于普通的服务器来说，这是比较危险的。尽管当前系统运行可能比较平稳，但运维技术人员绝对有必要考虑中期解决方案。

容量规划中的另外一个重要参考维度是 Web 访问日志的趋势图。对于中小网站来说，Awstats 足以胜任，更大一点的规模或是对统计要求更高的站点或许只能自己写统计工具了，还没听说有什么针对大型网站而且性价比好的商业工具。这里笔者要强调一下的是，商业站点尽量不要用第三方的流量统计工具，这样很容易泄漏比较关键的商业信息。

补充后记

容量规划其实远远不止这些，比如应用服务器容量规划方面、数据库容量规划，主机容量规划、存储容量规划等等，把整个架构拆成各个组件，每个组件的容量规划都是值得大书特书的一块内容。

另外一个关键点是团队的"容量规划"，团队成长这一方面如果跟不上也很容易成为瓶颈。

未完待续，下一篇谈一下关于《流程规范》的事儿。

接上一篇的《关于可用性》，再谈一下监控与报警机制。

监控机制

定义了网站可用性指标，如何获取网站的可用值? 监控工具该粉墨登场了。

多数网站都会倾向于利用开源软件自行搭建监控平台。笔者一向认为，即使网站有一台服务器，也应该搭建监控工具，这是保障网站能持续改进的基石。常见的开源监控工具有Nagios（www.nagios.org）、monit（www.tildeslash.com/monit）等。Nagios也可能是当前国内最被广泛采用的监控软件了，根据官方描述，Nagios 是开源的主机、网络、服务监控程序，从这个描述能看出，Nagios 的设计目标是很庞大的。依赖其强大的扩展性，通过分布式监控模式，管理上千台甚至更多的服务器也不在话下。而对于大型集群环境，Ganglia (http://ganglia.info/) 是个不错的选择。

另外商业化运作的比较好的开源监控工具或框架还有 Zenoss (http://www.zenoss.com/)、Zabbix (http://www.zabbix.com/)、Hyperic (http://www.hyperic.com/)、 OpenNMS(http://opennms.org/) 等。这几个的定位都是"企业级"监控平台。当然，功能的确不比 Nagios 差，也有的弥补了 Nagios 的一些不足之处(比如 Zenoss 增强了对 Windows 服务器的监控能力)。但出于种种原因，在国内的流行程度并不广泛。

(图2: Nagios 分布监控示意图
图片来源: http://nagios.sourceforge.net/docs/3_0/images/distributed.png)

如果要满足日趋灵活的 Web 监控需要就不得不提 Nagios 灵活的插件机制，最简单只需要几行 Shell 代码就能实现基本的插件功能。多数情况下，脚本捕获系统日志中的特定事件，通过 NSCA Client 发送给中心监控服务器即可。灵活性是衡量监控软件的一个重要标准，从这一点说，多数传统的商业网管软件怕是都不如 Nagios 这样胜任现在日趋复杂的网站环境。

提到网管监控，必然要谈到 SNMP。跨平台或者针对专有设备的监控离不开SNMP，但有的时候 SNMP 的安全性也的确会带来严重问题。这就需要运维团队中的安全专家对监控系统机制的安全性做整体评估，或是提升运维团队的安全意识以避免在监控过程中引入更多的安全问题。

有些公司的运维团队喜欢自己写监控工具而不是利用已有的第三方开源工具。这种重复发明轮子的做法笔者认为是不可取的。这样做最明显的一个缺点是软件本身的维护成本可能会更高，而且团队人员变动的时候后续代码维护也是个潜在的问题。至于商业工具的选择，这里不作评价。

报警机制

光有监控而报警机制跟不上，不能及时把紧急情况下的信息传递给运维技术人员，那么监控形同虚设。现在报警信息发送途径主要有邮件、IM、SMS 三种(过去书籍中提到的传呼方式已是明日黄花)。

这几个途径中，邮件告警可能是最简单的，实现起来容易，一行命令即可做到，但因为邮件本身的异步属性和邮件服务器的延时问题，很难让运维人员及时得知信息。所以，如果比较严重的告警信息必须考虑其它实时性比较高的方法。至于发送到 IM，如果 IM 是支持 Jabber 的，实现起来并不难，可靠性也会有一定保障，而如果 IM 比较封闭，那么可行性就不大了，除非 IM 公司对你开放 API ，否则任何取巧的技巧来发送消息的方法其可信赖性都不强、SMS 是大家都比较倾向的一种方式，只是有很多人不知道具体如何实现，说白了也就是一层窗户纸。如果有电信服务提供商(SP)能够提供基于 Web 的调用接口给你，那么直接利用 Wget 或是 cURL 工具模拟浏览器处理表单信息即可，几行命令即可搞定。如果不具备这样的条件，不妨考虑一下短信 Modem，现在市场上这样的短信 Modem 很多，价格不贵，大多都提供二次开发的功能，简单的写点脚本即可实现目的。至于网上有人推荐的免费短信服务，因为实时性比较差，笔者是不推荐的。天下没有免费的午餐，这样的服务往往信息发送优先级很低，而且，短信到达率很难保障。

值得一提的是，报警服务器本身也需要监控的。建议定期发送测试邮件、测试短信来验证告警功能处于正常状态。尤其是在节假日来临前更要反复确保该功能是正常可用的。

未完待续，下一篇谈一下《容量规划》。

这是前一段时间投稿给《程序员》的一篇文章。标题中的"道"有些大了，您可以理解为"门道"的"道"。一家之言，妄自言道，诚可笑也。

什么是网站运维(Web operations) ？运维，绝不是某些人眼中安装系统、做几根网线那么简单? 除去应用开发和业务运营之外的保障网站能运转的事儿都可能是运维工作的职责范围。运维的工作包括(但不限于) 软硬件部署、网络管理、应用程序维护、安全、容量规划、故障修复等等。

运维，有别于"运营"。在中文的语境中，运营更多和业务结合在一起的。而运维，则是偏向技术层面。

任何一个成功的站点都离不开一只优秀的运维团队，尽管他们更多时候隐身在网站背后不为人知。

网站可用性

所谓网站可用性(availability)也即网站正常运行时间的百分比，这是每个运营团队最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于 Web 站点来说，传统的那个 24x7 的说法已经不是很适用了，现在业界更倾向用 N 个9 来量化可用性， 最常说的就是类似 "4个9(也就是99.99%)" 的可用性。看一下表 1 能更为直观一些。

根据墨菲定理的推论，世界上没有 100% 可靠的 Web站点(除非不运行)。业界网站的可用性都是多少？引人注目的 Web 新贵 Twitter (http://twitter.com)， 2008 年前四个月的可用性只有 98.72%，有 37小时 16分钟不能提供服务，连2个9 都达不到，甚至还没达到"基本可用"状态。电子商务巨头 eBay 2007 年的可用性是 99.94%，考虑到 eBay 站点的规模与应用的复杂程度，这是个很不错可用性指标了。Web 应用类型决定了不同的站点对可用性的依赖性是不同的。 要知道 4 个 9 的可用性实际上是很难实现的目标。至于 5 个9 的 Web 站点，一半靠内功，另一半恐怕是要靠点运气。

(图1 维基百科网站的一台数据库服务器的可用情况报告, 由Nagios的监控得到的)

多数情况下，网站可用性会是 SLA （Service Level Agreement, 服务水平协议) 中的一个重要度量指标，也是运维团队向自己的客户(更多是公司老板)的正式承诺。可用性是能够持续改进的东西，KPI 制定者切不可狮子大开口，企图一步登天，拍拍脑袋提一些不太切实的指标。运维团队对可用性的承诺也不能开些空头支票，到头来两头难看。值得强调的是，如果是做第三方托管，更需要明确 SLA，明了第三方的服务能力，否则，费尽了九牛二虎之力终于保证了软硬件网络等环节都没问题了，IDC 却频繁断电或者IDC 出口网络不可用，这也绝对做不到预期的高可用性。

提高可用性的一些常规策略有消除单点，部署冗余设备(或集群)，配置带外管理网络等，对可用性要求不高的网站这些可能足够了。如果要提供更高的可用性，比如 4 个 9 甚至 5 个9，就不是简单靠硬件就能做到的事情，还需要建立完善的流程制度、建立变更机制、提升事故响应速度等。正所谓是"没有最高可用，只有更高可用性"。

一般来说，所有的网站运维人员都在追求网站的更高级别的高可用性，但是必须注意，这是以额外的软硬件投入、更多的人力成本为代价的。成本与可用性之间也请做到良好的平衡，盲目追求高可用性是不可取的。

(补充：Twitter 的可用性现在已经有了很大提升，但是可以看到，可用性不佳并非一个网站的杀手，只要产品对用户足够友好，足够有粘度，足够不可或缺，那么可用性并非是第一要追求的运维目标。有些运维人员被 Amazon 的某年圣诞节期间宕机所造成的影响埋下心理阴影，其实没那么可怕，如果真的觉得可怕，那么你可能被一些厂商销售人员洗脑了。)

未完待续: 下一篇《监控与报警》

Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。

iPhone 在市场上的优异表现，让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。

--EOF--

Web 前端优化最佳实践第六部分面向 图片(Image)，这部分目前有 4 条规则。在最近的 Velocity 2008 技术大会上，Yahoo! 的 Stoyan Stefanov 做的 Image Optimization: How Many of These 7 Mistakes Are You Making 也非常有参考价值。结合一起说一下。

1. 优化图片 (Optimize Images)

使用 GIF 、JPG 还是 PNG 格式的图片? 尽可能的使用 PNG 格式的图片，更多的功能，更小的尺寸(与 GIF 相比)。

对于 PNG 图片，考虑用 Pngcrush 或类似的工具进行优化。常见的工具如下表:

• pngcrush http://pmt.sourceforge.net/pngcrush/
• pngrewrite http://www.pobox.com/~jason1/pngrewrite/
• OptiPNG http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ (refer: 教程)
• PNGOut http://advsys.net/ken/utils.htm

对 JPEG 图片的优化工具：

• jpegtran (http://jpegclub.org/)

必需要强调的是，图片设计的同学啊，请考虑设计面向 Web 的图片，不要动不动就设计超过可接受尺寸之外大家伙，这应该是一种习惯，而不是什么高超的技能，只需要记住就成了。

2. 使用 CSS Sprites 技巧对图片优化 (Optimize CSS Sprites)

之前提到过，简单的说就是"利用 CSS background 相关元素进行背景图绝对定位"，把多次 HTTP 调用变为一次调用，更多参考：CSS Sprites: Image Slicing's Kiss of Death

补充一下：对于这个技巧我曾经见到有人滥用的。把多个背景图片揉成一个，减少　HTTP 调用，这是一个很好的思路。但一定要记住这个大图片不能太"重"，我看到过 100 多K 的背景图。一个图片就把整个网站拖得很慢。比较好的例子可以参考雅虎关系的这个图.

3. 不要在 HTML 中使用缩放图片 (Don't Scale Images in HTML)

更多的时候，可能是因为偷懒而没有制作合适大小的图片，如果是批量处理图片的话，可能一条 ImageMagic 命令（convert ）就能搞定 。必须提及的是，看到太多的对图片拉伸很难看的页面，救救这些页面!

4. 用更小的并且可缓存的 favicon.ico (Make favicon.ico Small and Cacheable)

更小，可缓存，这两条可能都不是问题。问题是，太多站点根本没有 favicon.ico 。有的时候，判断独立域名的 Blog 是否专业，基本看一下是否有 favicon.ico 就差不多了。

--EOF--

Web 前端优化最佳实践之 JavaScript 篇，这部分有 6 条规则，和 CSS 篇 重复的有几条。前端优化最佳实践，最重要的还是"实践"，要理解这东西容易得很，关键是要去"实践"，去"执行"，去"反馈"，去获取受益。

1. 脚本放到 HTML 代码页底部 (Put Scripts at the Bottom)

当一个脚本在下载的时候，浏览器干不了其它的事儿(串行了)。所以，把它扔到最后面去处理。对于一些功能性的脚本，可能实现起来有些两难。不过对于国内网站来说，有很多使用 Google Analytics 服务进行网站数据分析的。这这一点来说，绝对可行的建议，放到页面最底下。

2. Make JavaScript and CSS External

参见 CSS 篇的描述

3. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)

参见 CSS 篇的描述

4. 移除重复脚本 (Remove Duplicate Scripts)

对于一些历史遗留站点或是论坛类的网站来说，这倒是比较常见的。接手维护人前后变化过多，每个人都有自己的一套。这就会带来一些潜在的麻烦。

5. 减少 DOM 访问 (Minimize DOM Access)

• 缓存已经访问过的元素 (Cache references to accessed elements)
• "离线"更新节点, 再将它们添加到树中 (Update nodes "offline" and then add them to the tree)
• 避免使用 JavaScript 输出页面布局--应该是 CSS 的事儿 (Avoid fixing layout with JavaScript)

6. Develop Smart Event Handlers

除了英文解释外，这里也提醒一下注意关于 Java Script 内存泄漏的问题。

另外推荐一篇《如何优化 JavaScript 脚本的性能》，关于 Ajax 优化指导原则，可以参见 提高 Ajax 应用程序性能，避开 Web 服务漏洞。

后记1) ：整理得差不多之后，发现网络上已经有一篇 《Yahoo!网站性能最佳体验的34条黄金守则》，是翻译稿。看来我做了一部分重复劳动。

后记 2)：CSS / JavaScript 都有优化规则。但似乎缺少了对 Flash 的优化实践。

--EOF--

Web 前端优化最佳实践第四部分面向 CSS。目前共计有 6 条实践规则。另请参见 Mozilla 开发者中心的文章：Writing Efficient CSS

1. 把 CSS 放到代码页上端 (Put Stylesheets at the Top)

官方的解释我觉得多少有点语焉不详。这一条其实和用户访问期望有关。CSS 放到最顶部，浏览器能够有针对性的对 HTML 页面从顶到下进行解析和渲染。没有人喜欢等待，而浏览器已经考虑到了这一点。

2. 避免 CSS 表达式 (Avoid CSS Expressions)

个人认为通过 CSS 表达式能做到的事情，通过其它手段也同样能做到而且风险更小一些。

3. 从页面中剥离 JavaScript 与 CSS (Make JavaScript and CSS External)

剥离后，能够有针对性的对其进行单独的处理策略，比如压缩或者缓存策略。

4. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)

如果没有 JavaScript 与 CSS 可能更好。但，这是不可能的，SO，尽量小点吧。语法能简写的简写。

5. 使用 <link> 而不是@importChoose <link> over @import

在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。

6. 避免使用Filter (Avoid Filters)

--EOF--

延伸阅读：

• 《Web 前端最佳实践之内容篇》
• 《Web 前端最佳实践之Server篇》
• 《Web 前端最佳实践之Cookie篇》

Web 前端优化最佳实践第三部分面向 Cookie 。目前只有 2 条实践规则。

1. 缩小 Cookie (Reduce Cookie Size)

Cookie 是个很有趣的话题。根据 RFC 2109 的描述，每个客户端最多保持 300 个 Cookie，针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多，比如 Firefox 是 50 个) ，每个 Cookie 最多 4K，注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了，对于 Cookie 最重要的就是，尽量控制 Cookie 的大小，不要塞入一些无用的信息。

2. 针对 Web 组件使用域名无关性的 Cookie (Use Cookie-free Domains for Components)

这个话题在此前针对 Web 图片服务器的讨论中曾经提及。这里说的 Web 组件(Component)，多指静态文件，比如图片 CSS 等，Yahoo! 的静态文件都在 yimg.com 上，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名 (yahoo.com) 的影响。

从这篇 When the Cookie Crumbles 能看出，MySpace 和 eBay 的 Cookie 都不小的，想必是对用户行为比较关心。eBay 前不久构造了 Personalization Platform ，就是从 Cookie 的限制中跳出来。

延伸阅读：

• 《Web 前端最佳实践之内容篇》
• 《Web 前端最佳实践之Server篇》

--EOF--

Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的优化规则也由 13 条到 14 条，再到 20 条，乃至现在的 34 条--真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。

面向内容的优化规则目前有 10 条。

1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests)

作为第一条，可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析，有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求：

• 1) 合并文件，比如把多个 CSS 文件合成一个；
• 2) CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位；参见：CSS Sprites: Image Slicing's Kiss of Death
• 3) 图像地图
• 4) 内联图象 使用 data: URL scheme 在实际的页面嵌入图像数据.

2. 减少 DNS 查找 (Reduce DNS Lookups)

必须明确的一点，DNS 查找的开销是很大的。另外，我倒是觉得这是 Yahoo! 所有站点的通病，Yahoo！主站点可能还不够明显，一些分站点，存在明显的类似问题。对于国内站点来说，如果过多的使用了站外的 Widget ，也很容易引起过多的 DNS 查找问题。

3. 避免重定向 (Avoid Redirects)

不是绝对的避免，尽量减少。另外，应该注意一些不必要的重定向。比如对 Web 站点子目录的后面添加个 / (Slash) ，就能有效避免一次重定向。http://www.dbanotes.net/arch 与 http://www.dbanotes.net/arch/ 二者之间是有差异的。如果是 Apache 服务器，通过配置 Alias 或mod_rewrite 或是 DirectorySlash 能够消除这个问题。

4. 使得 Ajax 可缓存 (Make Ajax Cacheable)

响应时间对 Ajax 来说至关重要，否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。

5. 延迟载入组件 (Post-load Components)

6. 预载入组件 (Preload Components)

上面两条严格说来，都是属于异步这个思想灵活运用的事儿。

7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)

8. 切分组件到多个域 (Split Components Across Domains)

主要的目的是提高页面组件并行下载能力。但不要跨太多域名，否则就和第二条有些冲突了。

9. 最小化 iframe 的数量 (Minimize the Number of iframes)

熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。针对前端优化来说 iframe 有其好处，也有其弊端，一分为二看问题吧。

10. 杜绝 http 404 错误 (No 404s)

对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误，亦能提升用户体验。值得一提的是，CSS 与 Java Script 引起的 404 错误因为定位稍稍"难"一点而往往容易被忽略。

这是内容篇的 10 条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来。

--EOF--

点击流(用户访问路径分析) 似乎是互联网站必须要做的一件事情（我是 UE 门外汉）。如何从千差万别的用户访问行为发现共性，是个很有趣的可研究的东西。不知道这个地方是属于 BI 的活儿还是属于 UE 的（我是门外汉，只是对这个话题好奇罢了）。

类似的话题其实以前车东写过，几年过去了，用于进行 ClickStream 分析的开源工具真的不是很多(这或许也反应了业界对其需求吧)。常见的有 StatViz 、Pathalizer ，还有 Visitors 。

辅助工具有 ZGRViewer 、Graphviz等。

php statviz.php --config dbanotes.conf 
dot -Gsize="4096" -Tpdf -o mysite_clickstream.pdf "pairs.dot" 

第二行即为 Graphviz 在 Unix 下的基本使用。Ubuntu 系统上可以直接用 apt-get 安装 Graphviz 。

对于 StatViz 的聚合分析模式，觉得对站点分析价值不大。倒是 Individual Session Tracks (现在很多公司可能都自己开发类似的模块了)这个功能值得搞一下，可惜很多人都是集中于前者。对于中大型的站点，可以选择少数服务器激活 mod_usertrack ，收集有代表性的数据进行下一步分析。

Clickstream 这玩意儿是不是必须的? 前一段时间看云风的回忆，对"引擎加入录象" 这个细节印象很深刻。一个很复杂的系统如果缺乏缺陷捕捉能力，那么无疑不是很完美的系统。对于复杂得如迷宫一样的互联网站点，其实也是这样，你知道你的用户怎么访问自己的站点么?

--EOF--

根据 Session ID 跟踪输出的一份样例图:

偶然发现 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

• Nginx实践1 利用proxy_store实现高效的静态文件分布缓存服务器

对这篇《闲谈 Web 图片服务器》做了补充修正之后，在本期的《程序员》杂志上发表了。不过有朋友提出了一个问题：为什么说 Squid 不适合用 RAID 5　?

大家都知道 RAID 在写性能上因为存在校验，这句话的主要意思还是 Squid Cache 盘/ Cache 目录的问题(而不是放置图片的 RAID 5 磁盘)，在 Squid 满了的情况下，如果占用 Cache 盘，这个盘如果是 RAID 5 ，那肯定性能糟糕的一塌糊涂。另外一个原因是这部分其实不需要 RAID 来提高可靠性的，坏了完全可以 重新构建即可。

可惜我手边没有 Squid 服务器，要不倒是可以用数据来说话的。

参考文档: （一）、 （二），这两个参考信息其实比较旧的了

--EOF--

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名

如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我，"一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?" ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看--介绍这 14 条规则的页面本身也只能得到 70 多分...其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。

服务器端的 Cache

在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。

高解析图片问题

如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)...这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些"截屏"得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。

--EOF--

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report，如果图片处理量巨大，性能问题又怎能不考虑?

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

豆瓣的第二台应用服务器终于投入了使用。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 上留言的确用户体验很糟糕(我也很烦),相信本周末能得到解决。

邮件列表里看到的消息。AWStats 6.7 正式版发布了。新特性/改进列表:

- Full support for -day option. To build different report for each day
- Added virtualenamequot tag
- Added option NotPageList
- Addes .jobs and .mobi domains

对于第一条，按日构建报告其实从 6.5 版本以后就提供了相关功能。6.7 版本说是 "Full Support"，没看明白怎么个 "Full"。更多内容可以参考车东的AWStats的千万级日志解决方案。

--EOF--

在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

--EOF--

看这个题目可能有人会有疑问，SNS 站点和水葫芦有啥关系?

周六周日和项目团队去华庄生态农业园玩了一次，钓鱼，钓龙虾都挺有趣的. 不过给我印象最深还是水道上到处可以看到的水葫芦。有的地方已经占据了大半的水面。据说这玩意儿已经在滇池、太湖以及不少水域肆虐多时，因为繁殖飞快，很难根治。其危害来自"生长中消耗大量溶解氧，又会加剧水体富营养化"，最近又有"专家"要用这玩意儿以毒攻毒对付蓝藻，我看完全是欠抽。

网络上也有'水葫芦', 在 SNS 站点里尤甚。拿我在 Wealink 中的体验来说，里面所谓的从事猎头和营销的用户就和水葫芦差不多，拥有几千个'连接'的猎头不在少数，而且这些人在里面折腾的还挺欢，每天收件箱里面都能收到转发来的所谓体现"人生智慧"之类的玩意儿。以致于我现在看到猎头人员发来的连接请求一律拒绝。记得很久以前 Wealink 还是不能主动和联系人断开链接的，我申请了几次后新功能也开发出来了。新型 Web 2.0 站点是这样，其实传统的论坛里也存在类似的情况，我以前喜欢去的一个技术论坛，就是因为有些用户大量的自我繁殖，发送格调低下的垃圾信息而导致不少用户流失，当然，很多站长还是喜欢这样的"水葫芦用户"，毕竟带来了更多的 PV --垃圾 PV。

水葫芦消耗大量氧气，而"水葫芦用户"消耗大量网站资源，水葫芦使水体富营养化，使得其他生物大量死亡，"水葫芦用户"使得 SNS 站点"富信息化"--导致其他用户信息过载。这一点不少 Twitter 用户也深有体会吧?! 水葫芦破坏生态，"水葫芦用户"破坏一个社区的生态，而且会"暗示"更多的用户加入水葫芦的行列，如果不信的话，看看那些喜欢树立 "用户标兵" 的站点(比如新浪)就知道了。

任何站点都不可能没有"水葫芦用户"，关键还是看管理者的态度。有些听之任之，甚至喜欢"水葫芦用户"带来的虚假繁荣，短期内可能好像有所收益，长期来看，最受损伤的还是站点自身。

国内的站点中，豆瓣在这克制水葫芦用户上做得很好，值得表扬。

--EOF--

今天将 dbanotes.net 所用的 Movable Type 从 Beta 2 升级到了 Beta 5 测试了一下，遇到了大小毛病都有，不得不退回来。有些怀疑这个 MT 4 将会是一个比较失败的版本。

插件目录的变化

Beta 5 要求插件必须在 Plugins 目录下的子目录下，不允许脚本直接裸奔在插件目录下了。Beta 3 和 4 我没有还用过。不知道是从哪一个版本发生的变化。当然，这个变化不是问题，问题是即使这样设置了，很多插件仍然识别不到。包括 relatedkeyword.pl 插件。这个插件虽然简单，但却是我原来 Blog 不可或缺的。

更新导致的数据库错误

如果重复运行了升级操作，似乎就有这个问题:

lib/MT/Author.pm line 337

可以参考论坛上提供的修改数据库的解决办法。

Media Manager 插件不兼容

因为 Media Manager 不兼容会带来如下错误信息：

Unknown action mm_entry_edit

这个插件作用不大，直接删掉。

Updated: 测试了一下 最新的 Beta 6 ，又回滚了

Beta 6 还是有新问题。MTinclude 后面的模块名字中间不能有空格。

--EOF--

中国雅虎站长工具又将新增一个产品：统计系统。

上手比较简单，只需要添加站点的相关述即可获取一段 JavaScript 脚本，把这段脚本粘贴到自己 Blog/页面模版中。稍后片刻即可看到数据了，数据更新还是比较及时的。数据展现的纬度也比较多，有些数据也是直接针对中文用户而展现的(比如 PV 与 IP 单独的统计与对比)，从这一点来说，倒是比 Google Analysis 更为贴近用户。

统计数据可以选择是否公开，如果公开的话，还可以接受留言，这是个很讨好用户的功能，促进个人站长之间的互动。

刚开始使用，参见 Blog 右下角的小图标 不少功能还没有完全体验到。回头再和大家交流一下经验。

--EOF--