<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>DBA notes</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/" />
    <link rel="self" type="application/atom+xml" href="http://www.dbanotes.net/atom.xml" />
   <id>tag:www.dbanotes.net,2008://1</id>
    <link rel="service.post" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1" title="DBA notes" />
    <updated>2008-07-04T14:06:45Z</updated>
    <subtitle>SELECT blog FROM Fenng.Thought 
 WHERE subjects IN (&apos;ORACLE&apos;, &apos;Web Arch&apos;, &apos;UNIX&apos;, &apos;Web 2.0&apos;, &apos;OPENSOURCE&apos;) ; 

     
        Weblog
                 Wiki
LinkLog
                 OpenRSS
Search
                                  Articles
                 About
               </subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type 4.2rc2-en</generator>
 

<entry>
    <title>Jiffy -- 端到端的 Web 性能评测框架</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/jiffy.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1463" title="Jiffy -- 端到端的 Web 性能评测框架" />
    <id>tag:www.dbanotes.net,2008://1.1463</id>
    
    <published>2008-07-04T13:25:17Z</published>
    <updated>2008-07-04T14:06:45Z</updated>
    
    <summary>前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。

而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似&quot;望闻问切&quot;的诊断方式，那么 Jiffy 就是 CT  检查了。



下图揭示了 Jiffy 的工作机制：



通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>前面几天介绍的 <strong>Web 前端优化最佳实践</strong> 系列离不开一个关键词：<a href="http://developer.yahoo.com/yslow/">YSlow</a>。简单的说，YSlow 是以最佳实践得到的<strong>规则</strong>为基础，进行 Web 页面的性能评估，并给出指导建议。</p>

<p>而 <a href="http://en.oreilly.com/velocity2008/">Velocity 2008</a> 上发布的 <a href="http://code.google.com/p/jiffy-web/">Jiffy</a> ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 <a href="http://billwscott.com/jiffyext/">Jiffy Firebug Extension for Firefox</a> ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似"望闻问切"的诊断方式，那么 Jiffy 就是 CT  检查了。</p>

<p></p>

<p>下图揭示了 Jiffy 的工作机制：</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="Jiffy.png" src="http://www.dbanotes.net/Images/Jiffy.png" width="506" height="604" class="mt-image-center" style="text-align: center; display: block; margin: 0 auto 20px;" /></span></p>

<p>通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 <a href="http://www.dbanotes.net/database/oracle_database_10g_xe.html">Oracle XE</a> 做性能信息存储的数据库，相信不就会完美支持 MySQL 。</p>

<p><a href="http://looksgoodworkswell.blogspot.com/2008/06/measuring-user-experience-performance.html">关心 UE</a> 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之 Mobile(iPhone) 篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server_mobile.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1454" title="Web 前端优化最佳实践之 Mobile(iPhone) 篇" />
    <id>tag:www.dbanotes.net,2008://1.1454</id>
    
    <published>2008-07-02T01:16:42Z</published>
    <updated>2008-07-02T01:29:39Z</updated>
    
    <summary>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--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。</p>

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

<p>这个似乎只是<a href="http://yuiblog.com/blog/2008/02/06/iphone-cacheability/">针对 iPhone 研究</a>的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。</p>

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

<h4>2. Pack Components into a Multipart Document</h4>
<p>把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之图象篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_image.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1453" title="Web 前端优化最佳实践之图象篇" />
    <id>tag:www.dbanotes.net,2008://1.1453</id>
    
    <published>2008-07-01T00:56:06Z</published>
    <updated>2008-07-01T01:12:43Z</updated>
    
    <summary>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/PNGOut http://advsys.net/ken/utils.htm

对 JPEG 图片的优化工具：

jpegtran (http://jpegclub.org/)

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

 2. 使用 CSS Sprites 技巧对图片优化 (Optimize CSS Sprites)
之前提到过，简单的说就是&quot;利用 CSS background 相关元素进行背景图绝对定位&quot;，把多次 HTTP 调用变为一次调用，更多参考：CSS Sprites: Image Slicing&apos;s Kiss of Death

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

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

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

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

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践第六部分面向 图片(Image)，这部分目前有 4 条规则。在最近的 Velocity 2008 技术大会上，Yahoo! 的 Stoyan Stefanov 做的 <a href="http://en.oreilly.com/velocity2008/public/schedule/detail/2405">Image Optimization: How Many of These 7 Mistakes Are You Making</a> 也非常有参考价值。结合一起说一下。</p>

<h4> 1. 优化图片 (Optimize Images)</h4>
<p>使用 GIF 、JPG 还是 PNG 格式的图片? 尽可能的使用 PNG 格式的图片，更多的功能，更小的尺寸(与 GIF 相比)。</p>

<p>对于 PNG 图片，考虑用 <a href="http://pmt.sourceforge.net/pngcrush/">Pngcrush</a> 或类似的工具进行优化。常见的工具如下表: </p>

<ul><li><strong><a href="http://pmt.sourceforge.net/pngcrush/">pngcrush</a></strong> http://pmt.sourceforge.net/pngcrush/ </li><li><strong><a href="http://www.pobox.com/~jason1/pngrewrite/">pngrewrite</a></strong> http://www.pobox.com/~jason1/pngrewrite/ </li><li><strong><a href="http://www.cs.toronto.edu/~cosmin/pngtech/optipng/">OptiPNG</a></strong> http://www.cs.toronto.edu/~cosmin/pngtech/optipng/</li><li><strong><a href="http://advsys.net/ken/utils.htm">PNGOut </a></strong>http://advsys.net/ken/utils.htm</li></ul>

<p>对 JPEG 图片的优化工具：</p>

<ul><li><a href="http://jpegclub.org/">jpegtran</a> (http://jpegclub.org/)</li></ul>

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

<h4> 2. 使用 CSS Sprites 技巧对图片优化 (Optimize CSS Sprites)</h4>
<p>之前提到过，简单的说就是"利用 CSS background 相关元素进行背景图绝对定位"，把多次 HTTP 调用变为一次调用，更多参考：<a href="http://alistapart.com/articles/sprites">CSS Sprites: Image Slicing's Kiss of Death</a></p>

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

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

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

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

<p>--EOF--<br />
</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之 JavaScript 篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_javascript.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1455" title="Web 前端优化最佳实践之 JavaScript 篇" />
    <id>tag:www.dbanotes.net,2008://1.1455</id>
    
    <published>2008-06-30T04:32:34Z</published>
    <updated>2008-07-02T01:42:24Z</updated>
    
    <summary>Web 前端优化最佳实践之 JavaScript 篇，这部分有 6 条规则，和  CSS 篇 重复的有几条。前端优化最佳实践，最重要的还是&quot;实践&quot;，要理解这东西容易得很，关键是要去&quot;实践&quot;，去&quot;执行&quot;，去&quot;反馈&quot;，去获取受益。

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)&quot;离线&quot;更新节点, 再将它们添加到树中 (Update nodes &quot;offline&quot; 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--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践之 JavaScript 篇，这部分有 6 条规则，和  CSS 篇 重复的有几条。前端优化最佳实践，最重要的还是"实践"，要理解这东西容易得很，关键是要去"实践"，去"执行"，去"反馈"，去获取受益。</p>

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

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

<h4>2. Make JavaScript and CSS External</h4>
<p>参见 <a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_css.html">CSS 篇</a>的描述</p>
<h4>3. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)</h4>
<p>参见 <a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_css.html">CSS 篇</a>的描述</p>
<h4>4. 移除重复脚本 (Remove Duplicate Scripts)</h4>
<p>对于一些历史遗留站点或是论坛类的网站来说，这倒是比较常见的。接手维护人前后变化过多，每个人都有自己的一套。这就会带来一些潜在的麻烦。</p>
<h4>5. 减少 DOM 访问 (Minimize DOM Access)</h4>
有三条指导建议:
<ul><li>缓存已经访问过的元素 (Cache references to accessed elements)</li><li>"离线"更新节点, 再将它们添加到树中 (Update nodes "offline" and then add them to the tree)</li><li>避免使用 JavaScript 输出页面布局--应该是 CSS 的事儿 (Avoid fixing layout with JavaScript)</li></ul>

<h4>6. Develop Smart Event Handlers</h4>
<p>除了英文解释外，这里也提醒一下注意关于 <strong>Java Script 内存泄漏</strong>的问题。</p>

<p>另外推荐一篇<a href="http://shiningray.cn/improve-javascript-performance.html">《如何优化 JavaScript 脚本的性能》</a>，关于 Ajax 优化指导原则，可以参见 <a href="http://www.ibm.com/developerworks/cn/web/wa-aj-speed.html">提高 Ajax 应用程序性能，避开 Web 服务漏洞</a>。</p>

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

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

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之 CSS 篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_css.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1452" title="Web 前端优化最佳实践之 CSS 篇" />
    <id>tag:www.dbanotes.net,2008://1.1452</id>
    
    <published>2008-06-27T11:53:14Z</published>
    <updated>2008-06-30T08:48:54Z</updated>
    
    <summary><![CDATA[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. 使用 &lt;link&gt; 而不是@importChoose &lt;link&gt; over @import
在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。 

6. 避免使用Filter (Avoid Filters)

--EOF--

延伸阅读：
《Web 前端最佳实践之内容篇》《Web 前端最佳实践之Server篇》《Web 前端最佳实践之Cookie篇》]]></summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践第四部分面向 CSS。目前共计有 6 条实践规则。另请参见 Mozilla 开发者中心的文章：<a href="http://developer.mozilla.org/en/docs/Writing_Efficient_CSS">Writing Efficient CSS</a></p>

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

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

<h4>2. 避免 CSS 表达式 (Avoid CSS Expressions)</h4>

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

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

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

<h4>4. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)</h4>

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

<h4>5. 使用 &lt;link&gt; 而不是@importChoose &lt;link&gt; over @import</h4>
<p>在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。</p> 

<h4>6. 避免使用Filter (Avoid Filters)</h4>

<p>--EOF--</p>

<p>延伸阅读：<br />
<ul><li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_content.html">《Web 前端最佳实践之内容篇》</a></li><li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server.html">《Web 前端最佳实践之Server篇》</a></li><li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_cookie.html">《Web 前端最佳实践之Cookie篇》</a></li></ul></p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之 Cookie 篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server_cookie.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1451" title="Web 前端优化最佳实践之 Cookie 篇" />
    <id>tag:www.dbanotes.net,2008://1.1451</id>
    
    <published>2008-06-25T00:50:28Z</published>
    <updated>2008-06-25T01:55:47Z</updated>
    
    <summary>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--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践第三部分面向 Cookie 。目前只有 2 条实践规则。</p>

<h4>1. 缩小 Cookie  (Reduce Cookie Size)</h4>

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

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

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

<p>从这篇 <a href="http://yuiblog.com/blog/2007/03/01/performance-research-part-3/">When the Cookie Crumbles</a> 能看出，MySpace 和 eBay 的 Cookie 都不小的，想必是对用户行为比较关心。<a href="http://www.dbanotes.net/database/ebay_personalization_platform_mysql.html">eBay 前不久构造了 Personalization Platform</a> ，就是从 Cookie 的限制中跳出来。 </p>

<p>延伸阅读：<ul><li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_content.html">《Web 前端最佳实践之内容篇》</a></li>
<li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server.html">《Web 前端最佳实践之Server篇》</a></li></ul> </p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之 Server 篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1450" title="Web 前端优化最佳实践之 Server 篇" />
    <id>tag:www.dbanotes.net,2008://1.1450</id>
    
    <published>2008-06-24T12:25:58Z</published>
    <updated>2008-06-25T10:01:45Z</updated>
    
    <summary>Web 前端优化最佳实践第二部分面向 Server 。目前共计有 6 条实践规则。【注，这最多算技术笔记，查看最原始内容，还请访问：Exceptional Performance : Best Practices for Speeding Up Your Web Site 】

1. 使用 CDN (Use a Content Delivery Network)
国内 CDN 的普及还不够。不过我们有独特的电信、网通之间的问题，如果针对这个作优化，基本上也算能收到 CDN 或类似的效果吧(假装如此)。【Tin 说国内 CDN 用的挺多，看看 CDN 厂商的市场就知道了，还没走入寻常百姓家】

2. 添加 Expires 或 Cache-Control 信息头 (Add an Expires or a Cache-Control Header)
各个浏览器都有针对的方案, Apache 例子【注意：下面的说明例子还不够精细，具体的环境上还要加一些调整】: 
ExpiresActive On
ExpiresByType image/gif &quot;modification plus 1 weeks&quot;

Lighttpd 启用 mod_expire 模块 后：

$HTTP[&quot;url&quot;] =~ &quot;\.(jpg|gif|png)$&quot; {
     expire.url = ( &quot;&quot; =&gt; &quot;access 1 years&quot; )
}

Nginx 例子参考:

location ~* \.(jpg|gif|png)$ {
  if (-f $request_filename) {
        expires      max;
    break; 
  }        
}


3. 压缩内容 (Gzip Components)

对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。或许有人担心对 CPU 压缩对于 CPU 的影响，放心大胆的整吧，没事儿。Nginx 例子：

gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;

另外参见：IIS 如何启用 Gzip 压缩? 

4. 设置 Etags (Configure ETags)

对于 Etag，可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前，可能互联网上绝大多数站点都对这个问题忽略了。当然，Etag 对多数站点性能的影响并不是很大。除非是面向 RSS 的网站。【看到有朋友批评说写的简略，并且说 IE 不支持 ETag。明确说一下：IE 支持 ETag，倒是使用 IIS 要注意相关 Etag Bug。】

补充：我的意思是&quot;很多网站在不注意的情况下都是打开 Etag 的，而没有网站关心如何用，消耗资源而不知。并不是说 Etag 不好，合理利用 Etag ，绝对能取得很好的收益.

5. 尽早刷新 Buffer (Flush the Buffer Early)
对这一条，琢磨了半天，貌似还是异步的思路。能更好的提升用户体验? 

6. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)
XMLHttpRequest POST 要两步，而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。 

前一篇：《Web 前端优化最佳实践之内容篇》 

下一篇分析一下 Cookie 。

--EOF--

Updated: 另请参见楼下高春辉的留言，很精彩。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Web 前端优化最佳实践第二部分面向 Server 。目前共计有 6 条实践规则。【注，这最多算技术笔记，查看最原始内容，还请访问：<a href="http://developer.yahoo.com/performance/rules.html">Exceptional Performance : Best Practices for Speeding Up Your Web Site</a> 】</p>

<h4>1. 使用 CDN (Use a Content Delivery Network)</h4>
<p>国内 CDN 的普及还不够。不过我们有<strong>独特的电信、网通之间的问题</strong>，如果针对这个作优化，基本上也算能收到 CDN 或类似的效果吧(假装如此)。【Tin 说国内 CDN 用的挺多，看看 CDN 厂商的市场就知道了，还没走入寻常百姓家】</p>

<h4>2. 添加 Expires 或 Cache-Control 信息头 (Add an Expires or a Cache-Control Header)</h4>
各个浏览器都有针对的方案, Apache 例子【注意：下面的说明例子还不够精细，具体的环境上还要加一些调整】: 
<pre>ExpiresActive On
ExpiresByType image/gif "modification plus 1 weeks"</pre>

<p>Lighttpd 启用 mod_expire 模块 后：</p>

<pre>$HTTP["url"] =~ "\.(jpg|gif|png)$" {
     expire.url = ( "" => "access 1 years" )
}</pre>

<p>Nginx 例子参考:</p>

<pre>location ~* \.(jpg|gif|png)$ {
  if (-f $request_filename) {
        expires      max;
    break; 
  }        
}</pre>

<p><br />
<h4>3. 压缩内容 (Gzip Components)</h4></p>

<p>对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。或许有人担心对 CPU 压缩对于 CPU 的影响，放心大胆的整吧，没事儿。Nginx 例子：</p>

<pre>gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;</pre>

<p>另外参见：<ul></li><a href="http://www.dbanotes.net/web/iis_gzip_compression.html">IIS 如何启用 Gzip 压缩? </a></li></ul></p>

<h4>4. 设置 Etags (Configure ETags)</h4>

<p>对于 <a href="http://www.dbanotes.net/web/http_11_etag_lastmodified.html">Etag</a>，可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前，可能互联网上绝大多数站点都对这个问题忽略了。当然，Etag 对多数站点性能的影响并不是很大。除非是面向 RSS 的网站。【看到有朋友批评说写的简略，并且说 IE 不支持 ETag。明确说一下：IE 支持 ETag，倒是使用 IIS 要注意相关 Etag Bug。】</p>

<p>补充：我的意思是"很多网站在不注意的情况下都是打开 Etag 的，而没有网站关心如何用，消耗资源而不知。并不是说 Etag 不好，合理利用 Etag ，绝对能取得很好的收益.</p>

<h4>5. 尽早刷新 Buffer (Flush the Buffer Early)</h4>
<p>对这一条，琢磨了半天，貌似还是<strong>异步</strong>的思路。能更好的提升用户体验? </p>

<h4>6. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)</h4>
<p>XMLHttpRequest POST 要两步，而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。 </p>

<p>前一篇：<ul><li><a href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_content.html">《Web 前端优化最佳实践之内容篇》</a></li></ul> </p>

<p>下一篇分析一下 Cookie 。</p>

<p>--EOF--</p>

<p>Updated: 另请参见楼下<strong>高春辉的留言，很精彩</strong>。</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web 前端优化最佳实践之内容篇</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_content.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1449" title="Web 前端优化最佳实践之内容篇" />
    <id>tag:www.dbanotes.net,2008://1.1449</id>
    
    <published>2008-06-24T10:28:41Z</published>
    <updated>2008-06-24T11:52:45Z</updated>
    
    <summary>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&apos;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 错误因为定位稍稍&quot;难&quot;一点而往往容易被忽略。

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

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的<a href="http://developer.yahoo.com/performance/rules.html">优化规则</a>也由 13 条到 14 条，再到 20 条，乃至现在的 <a href="http://developer.yahoo.com/performance/">34 条</a>--真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。</p>

<p>面向内容的优化规则目前有 10 条。</p>

<h4>1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests) </h4>
<p>作为第一条，可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析，有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求：</p>
<ul><li>1) <strong>合并文件</strong>，比如把多个 CSS 文件合成一个；</li>
<li>2) <strong>CSS Sprites</strong> 利用 CSS background 相关元素进行背景图<strong>绝对</strong>定位；参见：<a href="http://alistapart.com/articles/sprites">CSS Sprites: Image Slicing's Kiss of Death</a></li>
<li>3) <strong>图像地图</strong> </li>
<li>4) <strong>内联图象</strong> 使用 <a href="http://tools.ietf.org/html/rfc2397">data: URL scheme</a> 在实际的页面嵌入图像数据.</li></ul>

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

<h4>3. 避免重定向 (Avoid Redirects)</h4>

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

<h4>4. 使得 Ajax 可缓存 (Make Ajax Cacheable)</h4>
<p>响应时间对 Ajax 来说至关重要，否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。 </p>
<h4>5. 延迟载入组件 (Post-load Components)</h4>
<h4>6. 预载入组件 (Preload Components)</h4>
<p>上面两条严格说来，都是属于<strong>异步</strong>这个思想灵活运用的事儿。</p>
<h4>7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)</h4>
<h4>8. 切分组件到多个域 (Split Components Across Domains)</h4>
<p>主要的目的是提高页面组件并行下载能力。但不要跨太多域名，否则就和第二条有些冲突了。</p>
<h4>9. 最小化 iframe 的数量 (Minimize the Number of iframes)</h4>
<p>熟悉 SEO 的朋友知道 iframe 是  SEO 的大忌。针对前端优化来说 iframe 有其好处，也有其弊端，一分为二看问题吧。</p>
<h4>10. 杜绝 http 404 错误 (No 404s)</h4>
<p>对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误，亦能提升用户体验。值得一提的是，CSS 与 Java Script 引起的 404 错误因为定位稍稍"难"一点而往往容易被忽略。</p>

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

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>关于 Discuz! 的二次开发</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/discuz.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1437" title="关于 Discuz! 的二次开发" />
    <id>tag:www.dbanotes.net,2008://1.1437</id>
    
    <published>2008-06-12T11:50:19Z</published>
    <updated>2008-06-24T07:03:12Z</updated>
    
    <summary>可能是因为 Discuz! 庞大的用户群的原因吧，发现有些中小网站也有在 Discuz! 基础上做二次开发的，巧的是，到了某个阶段，不约而同的遇到类似的问题：开发进度明显滞后。

个人觉得 Discuz! 设计的初衷是面向中小站长的，对于二次开发可能并不是很重视。去官方论坛看了半天，甚至都没有专门二次开发的板块。莫非大家的二次开发都是各自为政，摸着黑搞的么?(好像的确是这样，代码开源，对着修改就成)  一些简单的门户开发估计问题都不大的，如果业务复杂一些，并且流量相对较大，可能隐忧就会比较明显了。

有次因为要验证一点东西，看了一点 Discuz! 的代码，发现一些基本的模块性能上并非很好(我自己并不很懂 PHP，只是出于性能考虑罢了)，类似的页面在一定规模下并不会对性能有太大影响，可一旦突破某个量级，影响就非常明显了。有的网友可能会说，别装了，你不知道 Discuz! 功能有多强大吧? 问题可能恰恰就在于功能强大这儿了，一个软件如果自身已经在一些细节上考虑的足够细致，那么无疑也会给二次开发带来不必要的开销。就这一点上说，或许 Discuz! 有必要开发一个面向二次开发的版本，削减一些锦上添花的小功能。 

另外，UCenter 这个 SNS 产品我觉得也不会有太大作为，千站一面的 SNS ，除了让大家消磨一些无谓的时间，会带来什么创新呢?  

这只是我心血来潮，对产品设计的一点思考罢了，可别真的绕到 Discuz! 到底有哪些优点上去...

--EOF--

更新，有朋友和我说
Discuz! 代码里面本身包含监控隐私的东西，如果你的网站达到一定数量的用户，程序会触发通知 Discuz! 公司。
谁来证实一下? 

附加阅读:
百万记录级MySQL数据库及Discuz!论坛优化 -- Fenng 注：严格来说，百万记录级别并不是很大。但是一些思路非常值得新手借鉴。 </summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>可能是因为 <a href="http://comsenz.com/products/discuz">Discuz!</a> 庞大的用户群的原因吧，发现有些中小网站也有在 Discuz! 基础上做二次开发的，巧的是，到了某个阶段，不约而同的遇到类似的问题：开发进度明显滞后。</p>

<p>个人觉得 Discuz! 设计的初衷是面向中小站长的，对于二次开发可能并不是很重视。去官方论坛看了半天，甚至都没有专门二次开发的板块。莫非大家的二次开发都是各自为政，摸着黑搞的么?(好像的确是这样，代码开源，对着修改就成)  一些简单的门户开发估计问题都不大的，如果业务复杂一些，并且流量相对较大，可能隐忧就会比较明显了。</p>

<p>有次因为要验证一点东西，看了一点 Discuz! 的代码，发现一些基本的模块性能上并非很好(我自己并不很懂 PHP，只是出于性能考虑罢了)，类似的页面在一定规模下并不会对性能有太大影响，可一旦突破某个量级，影响就非常明显了。有的网友可能会说，别装了，你不知道 Discuz! 功能有多强大吧? 问题可能恰恰就在于<strong>功能强大</strong>这儿了，一个软件如果自身已经在一些细节上考虑的足够细致，那么无疑也会给二次开发带来不必要的开销。就这一点上说，或许 Discuz! 有必要开发一个面向二次开发的版本，削减一些锦上添花的小功能。</p> 

<p>另外，UCenter 这个 SNS 产品我觉得也不会有太大作为，千站一面的 SNS ，除了让大家消磨一些无谓的时间，会带来什么创新呢?  </p>

<p>这只是我心血来潮，对产品设计的一点思考罢了，可别真的绕到 Discuz! 到底有哪些优点上去...</p>

<p>--EOF--</p>

<p>更新，有朋友和我说<br />
<pre>Discuz! 代码里面本身包含监控隐私的东西，如果你的网站达到一定数量的用户，程序会触发通知 Discuz! 公司。</pre><br />
谁来证实一下? </p>

<p>附加阅读:
<ul><li><a href="http://shunz.net/2008/06/mysql_discuz_.html">百万记录级MySQL数据库及Discuz!论坛优化</a></li> -- Fenng 注：严格来说，百万记录级别并不是很大。但是一些思路非常值得新手借鉴。</ul> </p>]]>
        
    </content>
</entry>

<entry>
    <title>IIS 如何启用 GZip 压缩</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/iis_gzip_compression.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1436" title="IIS 如何启用 GZip 压缩" />
    <id>tag:www.dbanotes.net,2008://1.1436</id>
    
    <published>2008-06-12T00:14:58Z</published>
    <updated>2008-06-12T01:07:32Z</updated>
    
    <summary>微软 IIS 上如何启用 Gzip 压缩机制? 或许看过 YSlow 优化规则并且正在使用 IIS 的朋友比较关心这个问题。

基本步骤可以参考微软官方指导，直接一点的方式通过命令行执行如下命令启用对动态/静态内容的压缩输出: 

appcmd set config /section:urlCompression /doDynamicCompression:Trueappcmd set config /section:urlCompression /doStaticCompression:True

添加一个新的 Web Service Extension (如果原来没有的话) ，输入 gzip.dll 的全路径 。

IIS 6.0 上压缩额外的文件扩展名
修改 MetaBase.xml 文件中 HcFileExtensions 添加额外的文件扩展名。

IIS 7.0 上压缩额外的文件扩展名
修改 ApplicationHost.config 文件，添加合适的 mimeType 并指定激活. 打开文件参考原有的行照葫芦画瓢就成。可能要设置多次才会成功，因为 mimeType 定义可能有些歧义。

记录一下，备忘。

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>微软 IIS 上如何启用 Gzip 压缩机制? 或许看过 <a href="http://developer.yahoo.com/performance/">YSlow 优化规则</a>并且正在使用 IIS 的朋友比较关心这个问题。</p>

<p>基本步骤可以参考微软<a href="http://technet2.microsoft.com/windowsserver2008/en/library/05181f75-38c9-43e3-bc18-70596a23c3031033.mspx?mfr=true">官方指导</a>，直接一点的方式通过命令行执行如下命令启用对动态/静态内容的压缩输出: </p>

<pre>appcmd set config /section:urlCompression /doDynamicCompression:True<br />appcmd set config /section:urlCompression /doStaticCompression:True</pre>

<p>添加一个新的 Web Service Extension (如果原来没有的话) ，输入 gzip.dll 的全路径 。</p>

<h4>IIS 6.0 上压缩额外的文件扩展名</h4>
<p>修改 MetaBase.xml 文件中 HcFileExtensions 添加额外的文件扩展名。</p>

<h4>IIS 7.0 上压缩额外的文件扩展名</h4>
<p>修改 ApplicationHost.config 文件，添加合适的 mimeType 并指定激活. 打开文件参考原有的行照葫芦画瓢就成。可能要设置多次才会成功，因为 mimeType 定义可能有些<a href="http://www.coderjournal.com/2008/04/iis-7-compress-javascript-gzip/">歧义</a>。</p>

<p>记录一下，备忘。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web Clickstream 分析</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/web_clickstream.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1433" title="Web Clickstream 分析" />
    <id>tag:www.dbanotes.net,2008://1.1433</id>
    
    <published>2008-06-05T11:31:09Z</published>
    <updated>2008-06-06T09:57:11Z</updated>
    
    <summary>点击流(用户访问路径分析) 似乎是互联网站必须要做的一件事情（我是 UE 门外汉）。如何从千差万别的用户访问行为发现共性，是个很有趣的可研究的东西。不知道这个地方是属于 BI 的活儿还是属于 UE 的（我是门外汉，只是对这个话题好奇罢了）。

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

辅助工具有  ZGRViewer 、Graphviz等。

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

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

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

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

--EOF--

根据 Session ID 跟踪输出的一份样例图: 
</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>点击流(用户访问路径分析) 似乎是互联网站必须要做的一件事情（我是 UE 门外汉）。如何从千差万别的用户访问行为发现共性，是个很有趣的可研究的东西。不知道这个地方是属于 BI 的活儿还是属于 UE 的（我是门外汉，只是对这个话题好奇罢了）。</p>

<p>类似的话题其实以前<a href="http://www.chedong.com/blog/archives/001076.html">车东写过</a>，几年过去了，用于进行 ClickStream 分析的开源工具真的不是很多(这或许也反应了业界对其需求吧)。常见的有 <a href="http://statviz.sourceforge.net/">StatViz</a> 、<a href="http://pathalizer.sourceforge.net/">Pathalizer</a> ，还有 <a href="http://www.hping.org/visitors/">Visitors</a> 。 </p>

<p>辅助工具有  <a href="http://zvtm.sourceforge.net/zgrviewer.html">ZGRViewer</a> 、<a href="http://www.Graphviz.org/">Graphviz</a>等。</p>

<pre>php statviz.php --config dbanotes.conf <br />dot -Gsize="4096" -Tpdf -o mysite_clickstream.pdf "pairs.dot" </pre>

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

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

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

<p>--EOF--</p>

<p>根据 Session ID 跟踪输出的一份样例图: </p>
<a href="http://www.yupoo.com/photos/view?id=ff8080811a5b9cf2011a5d4a09bf3099" title="来YUPOO看我的照片"><img src="http://pic.yupoo.com/fenng/423995ac7ead/medium.jpg" alt="ClickStream 样例" width="347" height="364" border="0" /></a>]]>
        
    </content>
</entry>

<entry>
    <title>PHP FastCGI 进程管理器: PHP-FPM</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/php_fastcgi_phpfpm.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1423" title="PHP FastCGI 进程管理器: PHP-FPM" />
    <id>tag:www.dbanotes.net,2008://1.1423</id>
    
    <published>2008-05-22T13:57:16Z</published>
    <updated>2008-06-23T06:36:20Z</updated>
    
    <summary>最近 PHP-FPM (PHP FastCGI Process Manager) 这个话题在讨论组里很受关注。使用 PHP 的朋友对于 FastCGI 进程的管理估计都很头疼，比如 Nginx 下的 FastCGI 就有不少人用的 Lighttpd 的 spawn-fcgi 来对进程进行管理。但这样存在不少缺点(中文版本)。 

PHP-FPM 配置起来很简单，但有一点比较有意思的是如何确定 Worker 的数量。PHP-FPM 作者 Andrei Nigmatulin 在新闻组里提到的小技巧如下：

1) 用 Linux top 命令观察 (这个方式比较土)2) 用 &apos;netstat -np | grep 127.0.0.1:9000&apos; 收集数据。设置  php-fpm.conf 中的 max_children 的数值使 等待的数量变为最小。

目前使用 PHP-FPM 还只是通过 Patch 方式，然后编译，期待能够早点并入正式的 PHP 代码中。当然，PHP  核心开发的那些大爷们也不知都在忙什么呢，莫非还在为 Unicode 较劲呢? 

--EOF--

Tips : PHP-FPM on highload tips

</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>最近 <a href="http://php-fpm.anight.org/index.html">PHP-FPM</a> (PHP FastCGI Process Manager) 这个话题在讨论组里很受关注。使用 PHP 的朋友对于 FastCGI 进程的管理估计都很头疼，比如 Nginx 下的 FastCGI 就有不少人用的 Lighttpd 的 spawn-fcgi 来对进程进行管理。但这样存在不少<a href="http://none.at/phpfm/docs/current_php_fastcgi_problems_en.html">缺点</a>(<a href="http://syre.blogbus.com/logs/20092011.html">中文版本</a>)。 </p>

<p>PHP-FPM 配置起来很简单，但有一点比较有意思的是如何确定 Worker 的数量。PHP-FPM 作者 Andrei Nigmatulin 在新闻组里提到的小技巧如下：</p>

<pre>1) 用 Linux top 命令观察 (这个方式比较土)<br />2) 用 'netstat -np | grep 127.0.0.1:9000' 收集数据。<br />设置  php-fpm.conf 中的 max_children 的数值使 等待的数量变为最小。</pre>

<p>目前使用 PHP-FPM 还只是通过 Patch 方式，然后编译，期待能够早点并入正式的 PHP 代码中。当然，PHP  核心开发的那些大爷们也不知都在忙什么呢，莫非还在为 Unicode 较劲呢? </p>

<p>--EOF--</p>

<p>Tips : <a href="http://groups.google.com/group/highload-php-en/browse_thread/thread/e48a9fce7ee116ab/db412d43c1c3f36a?show_docid=db412d43c1c3f36a">PHP-FPM on highload tips</a></p>]]>
        
    </content>
</entry>

<entry>
    <title>侠客行恭候网络侠客</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/about_china_internet_developer_conference.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1422" title="侠客行恭候网络侠客" />
    <id>tag:www.dbanotes.net,2008://1.1422</id>
    
    <published>2008-05-22T04:36:27Z</published>
    <updated>2008-05-22T03:10:13Z</updated>
    
    <summary>后天，第二届中国网络工程师侠客行大会就召开了。届时，会有来自 Google、微软、雅虎的顶级专家进行技术分享。

Web 2.0 元素

和上次预告除了与会嘉宾稍稍有点出入的是，Yahoo! 旗下的 Flickr 这次会派出 John Thrall 进行题为 Flickr Architecture  的技术演讲。MySQL AB 公司创始人与 CTO David Axmark 将在上午有 Keynote。另外，下午还有 David Recordon 带来的 OpenID 话题。应该说这次会议也充满了 Web 2.0 技术元素的(其实个人觉得开放平台/SaaS 才是重点)。

关于门票
准备参加的朋友如果没有在网络报名打印报名表，我这里还有几张空余门票。给我留言，注明下午参加那个场次。我会回邮件告知电话，到时候在会场找我即可。

大侠风尚、Single Party
下午听完讲座后，可以用门票换取晚上的 大侠风尚和 Single Party 的门票。或许有朋友能结成良缘也说不定的:) 

小广告: 支付宝招聘
支付宝技术部近期在招聘。网站上有相对具体的 招聘要求，我们这边目前对架构师和 DBA 还是比较缺的。感兴趣的，联系我。

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>后天，<a href="http://info.china.alibaba.com/html/wx/index.html">第二届中国网络工程师侠客行大会</a>就召开了。届时，会有来自 Google、微软、雅虎的顶级专家进行技术分享。</p>

<h4>Web 2.0 元素</h4>

<p>和上次<a href="http://www.dbanotes.net/mylife/china_internet_developer_conference_2008.html">预告</a>除了与会嘉宾稍稍有点出入的是，Yahoo! 旗下的 Flickr 这次会派出 John Thrall 进行题为 Flickr Architecture  的技术演讲。MySQL AB 公司创始人与 CTO David Axmark 将在上午有 Keynote。另外，下午还有 <a href="http://www.davidrecordon.com/">David Recordon</a> 带来的 OpenID 话题。应该说这次会议也充满了 Web 2.0 技术元素的(其实个人觉得开放平台/SaaS 才是重点)。</p>

<h4>关于门票</h4>
准备参加的朋友如果没有在网络报名打印报名表，我这里还有几张空余门票。给我留言，注明下午参加那个场次。我会回邮件告知电话，到时候在会场找我即可。</p>

<h4>大侠风尚、Single Party</h4>
<p>下午听完讲座后，可以用门票换取晚上的 大侠风尚和 Single Party 的门票。或许有朋友能结成良缘也说不定的:) </p>

<h4>小广告: 支付宝招聘</h4>
<p>支付宝技术部近期在招聘。网站上有相对具体的 <a href="http://job.alipay.com/jobs.html">招聘要求</a>，我们这边目前对架构师和 DBA 还是比较缺的。感兴趣的，联系我。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Nginx 的推广问题</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/nginx_issue.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1421" title="Nginx 的推广问题" />
    <id>tag:www.dbanotes.net,2008://1.1421</id>
    
    <published>2008-05-17T15:37:36Z</published>
    <updated>2008-06-23T10:57:14Z</updated>
    
    <summary>偶然发现 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实现高效的静态文件分布缓存服务器
</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>偶然发现 <a href="http://www.nginx.net">Nginx</a> 稳定版本更新到了 <a href="http://www.nginx.net/CHANGES">0.6.31</a>，这个版本修正的第一个 Bug 值得注意：</p>

<pre>Nginx did not process FastCGI response if header was at the end of FastCGI record </pre>

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

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

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

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

<p>--EOF--</p>

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

<ul><li><a href="http://night9.cn/2008/05/24/252.html">Nginx实践1 利用proxy_store实现高效的静态文件分布缓存服务器</a></li></ul>
]]>
        
    </content>
</entry>

<entry>
    <title>浏览器针对单服务器连接数问题</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/browser_connections_per_server.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/MT/mt-atom.cgi/weblog/blog_id=1/entry_id=1419" title="浏览器针对单服务器连接数问题" />
    <id>tag:www.dbanotes.net,2008://1.1419</id>
    
    <published>2008-05-12T13:35:19Z</published>
    <updated>2008-05-12T14:07:49Z</updated>
    
    <summary>在修改后的 《闲谈 Web 图片服务器》 一文中也提及了&quot;IE 浏览器的连接数问题&quot;，这也是个有趣的话题。值得补充记录一下。



这个数据来自 Roundup on Parallel Connections ，这是一篇好贴，里面的每个线索几乎都值得一读(Opera 9 的连接数我做了修改)。以前经常看到某些优化 IE 或者优化 Firefox 的插件或工具，其工作原理也不过是针对这些相关的网络参数合理组合罢了。 好多朋友说 Opera 快，其实可能就是压缩和连接数两个做的更适合现在的网络吧。我不太相信内置解析器什么的真能比其它浏览器有什么质的领先。

其中 Firefox 3 的连接数目前还处于不确定中。对于网站维护人员，这是个非常值得重视的信息，我们总说蝴蝶效应，这恐怕就是最直接的例子了。一旦 IE 8 确定了新的默认连接数，并且短期内大量用户下载，有些网站如果不做调整的话，很可能会被击垮。

--EOF--
</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net/</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>在修改后的 <a href="http://www.dbanotes.net/web/web_image_server.html">《闲谈 Web 图片服务器》</a> 一文中也提及了"IE 浏览器的连接数问题"，这也是个有趣的话题。值得补充记录一下。</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="Browser_connections.png" src="http://www.dbanotes.net/Images/Browser_connections.png" width="523" height="99" class="mt-image-center" style="text-align: center; display: block; margin: 0 auto 20px;" /></span></p>

<p>这个数据来自 <a href="http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/">Roundup on Parallel Connections</a> ，这是一篇好贴，里面的每个线索几乎都值得一读(Opera 9 的连接数我做了修改)。以前经常看到某些优化 IE 或者优化 Firefox 的插件或工具，其工作原理也不过是针对这些相关的网络参数合理组合罢了。 好多朋友说 Opera 快，其实可能就是压缩和连接数两个做的更适合现在的网络吧。我不太相信内置解析器什么的真能比其它浏览器有什么质的领先。</p>

<p>其中 Firefox 3 的连接数目前还处于不确定中。对于网站维护人员，这是个非常值得重视的信息，我们总说蝴蝶效应，这恐怕就是最直接的例子了。一旦 IE 8 确定了新的默认连接数，并且短期内大量用户下载，有些网站如果不做调整的话，很可能会被击垮。</p>

<p>--EOF--</p>

<p><br />
</p>]]>
        
    </content>
</entry>

</feed> 

