在 IBM developerworks 网站看到一篇不错的介绍 Nginx 的文档：使用 Nginx 提升网站访问速度。针对其中的几个描述，我个人感觉不是很清晰：
# 目前官方 Nginx 并不支持 Windows，您只能在包括 Linux、UNIX、BSD 系统下安装和使用；
虽然 Nginx 官方并不提供 Windows 平台的下载，但还是有热心的开发者维护 Windows 平台上编译好的版本，而且，从邮件列表中观察了一段时间，和官方发布的版本基本上是同步的。
当然，我相信不太会有人在 Windows 上跑 Nginx 吧?
还有一句话我觉得也不太妥当：
# Nginx 本身只是一个 HTTP 和反向代理服务器，它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本，例如 PHP、CGI 等；
其实针对 Nginx 的内建的 Perl 模块现在就是支持的(当然，更准确的说是在实验阶段)。
–EOF–
很多 Discuz! 的用户在论坛规模达到一定程度上，就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验，应该说，很多经验还是不错的，但也有的帖子可能会让用户走入误区。
多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。
其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。
前面说，数据库”可能”是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。
应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。
静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。
对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译
这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。
这可能是比较普遍的”习惯”了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是”对”的话，那么效果看起来是好的。如果有的步骤调节”错”的话，可能会抵消那些有效果的优化步骤。
优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。
–EOF–
前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。
而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似”望闻问切”的诊断方式，那么 Jiffy 就是 CT 检查了。
下图揭示了 Jiffy 的工作机制：
通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不久就会完美支持 MySQL 。
关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。
–EOF–
更新：有得朋友说，安装了，点击了，没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。
Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。
这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。
iPhone 在市场上的优异表现，让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。
把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。
–EOF–
Updated: 根据这篇 iPhone caching 的文章，可供 Cache 的最大单个数据对象是 15K，而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。