易栈网-膘叔

上周六的phpchina搞的活动可以通过echo谈xhprof,cache and long-polling查看，其中echo的ppt可以在线观看了，当然你也可以下载到本地。

不得不说的是，ppt上可以展现的内容确实有点少，如果身在上海，没有去听echo讲课，确实有点遗憾。

PPT下载在这里：web_perf.pdf

pea的活动除了这次外，我是真没有参加过，不过在与会的同时听文峰说也好多时间没办了，所以也没有感觉啥。这次的内容主讲是蛋定工作室www.jt-tech.net的echo，讲了xhprof ,cache，以及long-polling的一些应用及讲解，因为对xhprof以及long-polling有点兴趣，所以就参加了。当然还有另外的原因：echo在群里研究session的时候，非常透彻，也想看看他平时用啥工具之类的；另外就是想看看11爷、四爷以及逍遥等人长啥样。
好象以前在drupal研讨会的时候见过文峰，应该也是4年前了吧，那时候好象他非常胖，也曾经找过我让我谈谈有没有什么 经验可谈的。
值此今天这一课，发现我还是离专业差的很远，都是走的野路子啊。果然是人不学习就要退步，野路子能走一时，是走不了一世的。
看着echo（蛋定工作室）的PPT上那些工具，发现，我除了x-debug外，真是一个都没有用过。丢人，不过想想也没啥，在篱笆的时候性能啥的都扔给运维了，当然他们也没有查出啥问题来，可能还是篱笆的访问量不大的原因吧？现在想想那样垃圾的代码都没有跑出问题而java的一跑就嗝屁了，也真是意外。
谈了很多废话，还是讲讲今天的内容吧，比较有印象的当然也正是我想了解和关注的xhprof以及long-polling。web client cache这玩意还真没有什么 可讲的，对着yahoo的14条军规慢慢查，慢慢改吧。【后来变22条军规了】
xhprof，是facebook提交的pecl库（好象Echo是这么说的），可以在运行时候查看效率，这点其实才是我最关注的。echo说xhprof对于那些只针对某些人出现问题，而其他用户死活折腾不出、故障BUG无法重现的性能优化、log记录非常有用。在看了他给出的wikimedia的图片，以及他实际项目中的代码片段后，觉得果然是非常有意义。对于性能的影响好象也不是很大。
xhprof，在这里我就不多介绍了，google搜索的第一条就是老王的笔记：体验XHProf_老王的技术手册_百度空间，想看的可以移步去参观一下，过两天我也会转到博客上来，毕竟这东西确实值得试一下，特别是想用在wordpress上，看看性能瓶颈到底在哪里，是否可以进行优化。

这张图真的很吸引我，可以让我检查页面中哪些地方消耗的资源最大：


long-polling，对于做WEB的人来说，特别是SNS的人，用的地方就多了。目前最多的用途可能就是用来检测是否有系统消息提示，如果一直用ajax，那么你会发现定期polling的时候，很耗资源。如果不信，你可以看一下thinksns，他取信息等 资料就是这样的处理。但其实long-polling也能算是用ajax在获取信息，但他连接后并不能算是断开，由服务器一直在while(true)循环。echo也给了一些测试代码。当然，其实这方面很早就研究和接触过，不过仅限于表面，因为我没有理解当并发非常大时候，这个性能如何处理。echo是说通过ulimit -n 来调整最大用户数和最大进程数来增加，因为理论上都是根据内存大小和利用率来控制，说白了，你没内存，代码再好也经不起折腾。并发也永远上不去。

很多东西，一时间可能用语言无法表达，但总算是有收获，最后抽奖的时候，报数时，号码是13，哦，原来我还是可以装 13的。over
看下一次是否再有收获。上大课确实不如上小课，有时候人多了并不一定能够讲得出话。
听说echo要把PPT放出来，到时候可以看看。
最后说一下web client cache。关于这个玩意，对于if-modified这东西等等，现在用的真是少了，以前在做垃圾网站时，都是强行指定e-tag，内容页的e-tag永远不变，首页、列表表的e-tag一天变一次，以保证性能的最大体现。其实，抛开用户登录，如果内容页是ajax的widget，那真的是可能永远不变的。不过现在都是为了更好的吸引用户，在cms中的相关文章、推荐文章、推广文章等 都是实时更新的，所以效率也相对下降一点点喽。不过，可以考虑e-tag为一天，这样对于当天频繁访问的用户速度会明显增加，但，不知道对搜索引擎会怎么样。
杂谈而己

这是一篇来自chinaz.com的文章，因为我有几个博客都采用了wordpress，而且我的手机博客上面有大量的图片，因此，Cache图片就成了重中之重的事情。看到这篇文章我就很开心了。很方便的使缓存过期时间设在了一个月后。很方便，用的也很爽。

原文如下：

WordPress博客里大量的图片会使页面加载速度变得缓慢。 此时访问者需要用更多时间才能打开一个页面。 不过我们可以通过缓存图片来解决这个问题。 当页面第一次被加载时，将所有图片存放在浏览器的缓存池里。 之后访问者再加载该页面时，浏览器就可以从浏览器缓存中获取图片，从而减少页面加载时间。

对Apache服务器上的WordPress博客/网站，可以通过编辑根目录下的.htaccess文件来激活图片缓存功能。 浏览器能够简单读取.htaccess文件的缓存控制头，而缓存头会要求浏览器将图片或其它任何媒体保留2周时间（或者更久），这样浏览器就能够随时调用 图片，直到图片过期。 两周后浏览器重新将过期的图片存入缓存。 万一浏览器缓存被清空，浏览器会从缓存中重新加载图片或其它媒体。

下面就是对如何在WordPress博客/网站上激活图片缓存的过程详解。

如果你希望提高网站的运行效率，就应该启用网络服务器上的图片缓存功能。 详细步骤如下：

注意：做任何改动前请先备份网站数据域.htaccess文件。

1. （在FTP中）打开根目录下的.htaccess文件

2. 在.htaccess文件中加入如下代码：

3. 编辑完毕后保存文件。 代码中“max-age”参数的值为2592000（秒），因此图片缓存和Flash内容缓存在浏览器中保留一个月。

如果这个方法能够奏效，你的网站访问速度将会有很大改善。

原文：Improve Performance by Image Caching of Wordpress Blog using htaccess trick（译 文）

我的文章来自于：http://www.chinaz.com/Webbiz/Exp/0406110L02010.html

很明显的可以看出是针对哪一类的文件进行了header缓存。如果不经常更改，相信这样是足够了。

本文来自于淘宝QA，这是第一次看到有这样的贴子，是测试cache的贴子。虽然他不是测试cache本身，但从文中的测试要点来说，还是有借鉴意义的。像他说的：触发点、何时使用cache等都是一个要点。
众所周知，任何一个程序，为了效率，总有部分资料是需要被缓存的。比如，系统配置，这玩意一旦设定，很可能就再也不会修改了（或者说，修改的频率非常低），如果每次都查询数据库，那效率也太低了。所以它应该是被缓存的对象之一。
分类也是应该能够被缓存的，谁TMD有事没事去修改分类、删除分类？一个成熟的网站，分类定下来后，基本也就定下来了，除非更改业务方向，增加业务范围，才会去修改分类。当然还有一种情况，那就是为了促销，人为修改（但这应该不属于分类了啦）所以，分类也应该是被缓存的对象之一。。。

好了不说废话了，看测试是怎么说的吧：
原文：http://rdc.taobao.com/blog/qa/?p=3434

        前段时间做了一个cache相关的接口测试，这里要说的并不是测试cache本身，而是测试一个使用了cache的业务系统，该业务系统通过调用另一个专 门提供cache服务的系统来实现数据的cache。也就是说cache服务本身对于我来说是黑盒的。那么在这种情况下，我们应该从哪些方面来考虑测试， 才能够保证业务系统对cache服务的调用是正确的呢？我是从以下几方面考虑的：

一．Cache的触发点

        如果一个系统使用了cache，那么它就一定会有cache的触发点，所谓触发点就是会触发cache缓存数据或者更新数据的事件。这些事件往往就是对某 些接口的调用。例如查询数据的时候，如果缓存里没有该数据应该会触发cache来缓存该数据。更新数据的时候，如果缓存里有该数据，应该会触发cache 删除该数据的缓存等等。我们必须要掌握每一个触发点才能够知道如何来设计针对cache的测试，因为我们的目的就是要验证所有的触发点是否都正确的触发了 我们所期望的缓存事件。

二．何时应该使用cache，何时应该使用数据库

         掌握了系统中所有的cache触发点之后我们就可以开始设计如何来验证这些触发点了。一般来说，被缓存起来的数据都是供查询使用的，明确了这点之后，其实 归结起来，我们只需要考虑两个问题：一是何时应该查询cache中的数据，二是何时应该查询数据库中的数据。

         举例来说，一个典型的使用了cache的查询接口应该是这样的，当查询数据的时候，接口会首先去缓存中查找数据，如果缓存中没有数据，再去数据库中查找， 如果在数据库中找到了指定的数据，它会在返回数据的同时，对该数据做缓存处理。了解了这个过程之后，你可以先通过直接插数据库的方式准备一条数据，这个时 候该数据是没有缓存的，因为没有触发缓存数据的事件发生，那你如何来验证这个数据确实没有缓存呢？很简单，直接把该数据从数据库删除掉，再调用查询接口查 询该数据，如果没有查询到，说明该数据确实没有被缓存。另外一方面，你还应该保证如果数据被查询到了，那么它就应该被缓存起来，这个时候你同样可以直接删 除数据库中的数据，再次查询该数据，如果可以查询到，那么就说明它确实是被缓存起来了。总的来说就是了解缓存过程，分解过程，保证过程的每一步结果都是所 期望的，这就有别于通常的接口测试只关注输入和最终的输出结果了。它的思想和切面编程的思想有点类似，也许我们可以把这种测试方法叫做切面测试。

三．多触发点联合测试

         在保证了每个触发点的正确性之后。我们还应该进一步把这些触发点按照实际的业务场景串联起来测试。例如，可能会有这样一个业务场景：生成数据→查询数据→ 编辑数据→查询数据→删除数据→查询数据。值得注意的是对于这样的联合测试除了保证每个步骤的结果都正确的同时，我们应该尽量采用调用业务系统接口的方式 来完成每一步，尽量避免直接操作数据库，因为这样更能模拟出真实的调用场景。

        不同的cache方式会有不同的测试方法，以上仅是我在测试特定cache的时候的一些想法，仅供参考。如果你测试过cache，不妨也来说说你自己的测试方法，如果你没有测试过cache也可以来谈谈自己的想法。

本则新闻自于Cnbeta.com，可惜我没有IIS 7及更高版本。否则倒可以尝试尝试。。http://www.cnbeta.com/articles/92522.htm

也许您同时喜欢PHP的开发速度和Windows的易用性,但PHP和Windows的配合似乎永远没有Linux好?今天微软终于可以让Windows的PHP用户向Linux下的朋友们炫耀一下:
Windows Cache Extension for PHP Beta 发布,这是一个面向PHP的Windows缓存扩展,用于提高PHP应用程序的速度,而且无需修改任何代码!支持IIS 7.5和IIS 7.0.

• PHP 5.2 and PHP 5.3 support
• Configurable file cache
• Configurable PHP opcode cache
• Relative file path cache
• PHP functions to obtain information about the cache status
•  

访问:Windows Cache Extension for PHP