这本书比上一本《高性能网站建设指南》更加的深入，虽然目前我只读到第六章内容，但是我已经把该书的等级从”推荐“改为”力荐“。

目前看到的对几个经典问题的剖析：javascript单线程问题，脚本拆分节省下载负载问题，行内脚本和外部链接脚本的加载过程以及对组件下载和渲染的影响，内存使用对响应时间的影响（其中提到了GC机制，对后端开发人员也有很好的参考价值）。

本书中出现了好几个我一直膜拜的javascript的牛人，其中有jquery框架的创始人，有jsmin的作者（一个js的压缩工具）。结合本书的javascript章节，我相信对javascript的机制会有个更加深入的了解。正如上一本书中所说，70%的页面响应时间都花费在浏览器端，这部分的优化对高负载流量站点来说不容忽视，不管是架构师，还是前台或者后端开发人员本书都有很高的参考和研究价值。

注：本书中部分章节需要有程序设计的基础知识，比如多线程和内存管理。

今天终于看完了所有章节，个人感觉后半部分三个章节内容写得不错。1，javascript代码优化。此部分内容不仅仅局限于javascript代码，对别的语言也是一个参考，（除了作用域对性能影响），因为大部分讲的是程序控制流程对语言性能的影响。
2，Gzip压缩。这个章节很有趣，分析了15%的用户在http请求头中为什么没有gzip。并给出了一些解决方案，这个章节的特约作者在上一本书中对gzip压缩也做了详细的介绍。书中那个性能对比图比较重要。
3，图像优化。可能做后端程序的人对这个方面不是很了解，这个章节刚好对我是个补充。以前项目涉及到图片的压缩率，处理图片的cpu占用率和图片压缩算法，加上这个章节的介绍，就更完美了。

我因为工作原因，曾经对Drupal做过比较全面的测试。当时的环境是双服务器（DB server+Web Server），硬件配置都是单CPU+4G。数据库里面有几千条记录。用JMeter对各种情况下（开/关各种cache模块，logged user/anonymous user）不同页面的读取和写入操作都进行过测试。 测试的结论可能和很多人印象中不一样。都说Drupal对数据库要求高，但事实上，无论是cache还是非cache模式，DB server的压力都是相当小的（CPU在10%以下），而Web Server的CPU在80%以上。跟踪所有的db query的执行时间后，也证明了这一点（全部db query的执行时间只占页面生成时间的一小部分）。所以结论是，Drupal在大量logged user并发情况下的瓶颈，在于执行Drupal代码的CPU时间。
之所以出现这种情况，和PHP本身的执行机制和Drupal的实现方式有关。Drupal在生成一个非cached的页面时，不管这个页面多么简单，都要执行一个完整的bootstrap过程，即使只启用了最少的模块，这个过程也要调用几十个PHP文件，执行成千上万行PHP代码。而PHP的机制又决定了没有任何PHP代码或者对象能够驻留内存，每次响应请求都必须执行完整的初始化工作。
而anonymous user之所以快，是因为Drupal在执行cached page的时候，不会执行完整的bootstrap过程，它先检查是否cached page，是的话就读取缓存，然后结束工作。这样当然就快了。
以这个结论为前提，可以解释一些事情：
1 为什么Drupal的性能在各种环境下相差并不多。无论是双服务器，单服务器，甚至内存非常小的虚拟机，logged user的RPS值总是在10~20之间。数据库里面有几百条，或者几十万条记录，影响也不大。因为瓶颈并不在于DB或者内存，而是在于执行代码的过程。
2 为什么使用APC/XCache这样的代码优化程序，能够得到极大的性能提升。在我自己的虚机环境上，RPS从3~4提升到了12。因为它提升的是PHP代码的执行时间。
从这个结论出发，列出一些对优化Drupal的logged user性能有明显作用和没有明显作用的措施：

没有明显作用的：
1 加内存。在并发数只有10+的时候，即使每个请求占10M内存，也只有100M+内存而已。
2 DB server和Web server分开，或者增强DB server的配置。一台中等性能的mysql服务器，应付200~300的并发是很轻松的事情，在并发数只有10+的时候，db server实际上闲得没事干。
3 基础软件的优化，例如从Windows转移到Linux，从apache转移到httpd，从MySQL迁移到其他数据库，除了从Windows转移到Linux会有比较明显的提升以外（因为提升了PHP的执行效率），其它的措施可能会快一些，但不会有数量级的提高，因为瓶颈不在那里。

有明显作用的：
1 使用APC/XCache这样的代码优化程序，速度会有几倍的提升。估计大家都已经这样做过了。
2 增加web server的CPU数量。双核的肯定比单核的快，8个CPU肯定比2个CPU快得多。
3 使用多web server+单db server的配置，把代码执行的压力分散到不同的web server上。上文说到，单台db server可以轻松应付200+的并发，这意味着理论上可以支持10台以上的web server。
4 使用Quercus这样的引擎，把PHP代码编译成Java，再在Java VM中运行，理论上会有很大的提高。原因是，第一，Java的运行效率比PHP高，第二，Java代码是可以cache的，不需要每次都重新加载。这里有个测试结果：
http://www.workhabit.org/resin-backed-php-drives-4x-performance-improvements-drupal
Drupal在Quercus下有4倍的性能提高，但是这个数字跟Drupal在打开APC/eAccelerator下的提升差不多，所以没有太大的价值。

另外一种思路是代码本身的优化。
使用cache API没有任何意义，因为logger user根本不用调用它。
Drupal.org上有人提出，即使是logged user，有很多页面也是不用定制化的，这意味着可以cache它们。但是Drupal没有提供这样一种机制。只要是logged user，Drupal就会执行完整的bootstrap过程，即使只打印出一个hello world，因此实际上你没有办法在logged user状态下cache单个页面。
我研究了一下Drupal的bootstrap过程，发现也许这样是可以的：实现hook_boot函数，这是bootstrap中执行最靠前的一个函数，它被调用时，bootstrap的大部分过程还没有执行。在hook_boot中，检查当前页面是否需要cache，如果是，直接读cache生成页面，然后调用exit()强行结束。这应该是可行的，但太过hack了一点。

另外，说说我对Drupal的看法。Drupal是我见过的web应用里面架构做得最好的一个（不仅仅是PHP，也包括Java和.NET应用）。在没有见过Drupal之前，我就想过，如果能把Eclipse的实现思路用web平台的方式实现，通过微内核+plugin实现所有的功能，那是一个多么方便的事情。接触Drupal以后，发现这就是我在寻找的东西。
从性能上来说，Drupal在anonymous user的情况下是非常优秀的，根据我以前的测试，基于file-based cache的插件，RPS在350以上，这意味着单机就可以实现万人在线的站点了。但是，Drupal在logged user的情况下性能不佳，这也是事实。RPS 10+可能也可以应付几百人在线的情况，但是想想同等配置下，原生PHP和Java都能到100+，还是很让人郁闷啊。