其实按时间的归档机制对于已经写了很多年的博客来说非常必要，除了方便用户和机器人查找旧文章外：你的博客终于有了一个文章从完全旧到新排列的视角，终于可以方便的从前往后看了…… 

比如看《我爱阿尔法女郎》 话剧前后：可以用归档页看看原作剧本；

如果你是Google Toobar的Heavy User：按向上按钮 从 /logs/2008/10/ 到  /logs/2008/ 到 /logs/ 到 / 都不会出现无内容页了，而且所有的内容都可以完整的导航；这就是所谓的Easy Navigation吧；

We’ve recently done benchmarks comparing different MySQL versions in terms of their CPU efficiently in TPC-C like Workload. We did it couple of weeks ago so MySQL 5.0.67, MySQL 5.1.29 and Innodb Plugin 1.0.1 were used which are not very recent, though we do not think results will differ a lot with today versions.

Results are as follows:

The system was 2* Quad Core Xeon E5310, CentOS 5, Data stored on ramfs. We controlled number of cores used with /sys/devices/system/cpu/cpuX/online Maximum performance for each number of cores was taken though it was reached with number of sessions matching number of cores. Just 1 “Data warehourse” was used to keep data small.

As you can see there is some gain for MySQL from read-write lock split patch (found in Percona Builds) though it is not very significant for this workload. To isolate effect of this patch we only use this patch not full patch set in testing.

MySQL 5.1 is 4% slower than MySQL 5.0 with two cores and just 2% slower with 8 cores, thus showing a bit better scalability.

MySQL 5.1 plugin (compiled in) is further 3% slower compared to MySQL 5.1 with 2 cores and about 6% slower with 8 cores, meaning regression from plugin increases with number of cores.

If you would not only run MySQL plugin but also use new “Barracuda” Innodb format you see just 1% slow down with 2 cores and about half percent with 8 cores which is what you can attribute to measurement error.

This tells us there are some workloads when MySQL 5.1 is slower than 5.0, and same applies to the new Innodb code. Well newer does not mean more efficient, on the contrary newer features often come together with larger code and longer execution path.

Another thing to note - if you’re using Innodb Plugin consider using new Barracuda format, though do this only after you have done your careful testing as this format will not be recognized by older Innodb versions.

Note: These are completely CPU bound test conditions, data fits to buffer pool furthermore data and logs are on ramfs so no IO is ever needed.

Entry posted by peter | 8 comments

Add to: | | | |

• 我们先从首页开始吧，如果用户并不使用您网站的搜索功能和下拉菜单，他们能方便地通过你提供的导航链接找到他们想要的信息么（比如篮球巨星的运球技巧）？

• 再比如说一个用户是通过一个外部链接找到您的网站的，但是他们首先到达的不是首页。不管用户首先来到的是哪一页，您都要确保他们能够顺利的找到首页及其他 相关部分的链接。换句话说，您要确保您的用户不会迷失方向。您的用户能方便找到“最佳运球技巧”吗？像“首页>技巧>运球” 这样的导航能够帮助用户了解自己所处的网页层次。

• 文字链接是很容易被搜索引擎发现的，如果您特别关注自己的内容是否能被正常索引的话，使用文字链接是一种比较稳妥的办法。可以想象您肯定也会采用一些最近的技术，但是无论怎样，文字链接对用户和搜索引擎来说都是更友好，更便于访问的。

• 提交网站地图对主要搜索引擎来说也很有帮助，尽管它不应该取代一个便于抓取的链接架构。如果您的网站使用一些更新的技术，比如AJAX，您可以参考下文中的“确认Googlebot能够找到您的内部链接”。

• MTOS-4.23-en.tar.gz
• MTOS-4.23-en.zip