翻译文章，仅供学习之用，版权归原作者所有。
原文网址：
http://www.svdgraaf.nl/2008/11/07/optimizing-your-zf-web-application/
来到
IDG之后，我们当前的工作就是把所有应用从PHP4代码基转移到PHP5代码基（每个人都应该这么做），这个过程中，我们还把所有的应用移植到Zend Framework中。在第一个项目改造完成，进入性能测试阶段时，我们遇到了大量的问题。我在这里列举了一些你可以避免的典型错误，请容忍我的唠叨。
几天前，我找到了一篇Till的
文章，该文列举了许多优化ZF应用的陷阱。尽管我们的项目不像他那个项目那样，拥有那么多的访问量，但是我们也没有那么多的硬件资源。我再强调一次，我们的硬件资源要比他的项目少很多。
对于我们的应用，我们的机器配置为：双核2G处理器、2G内存和一些scsi硬盘。而且2G内存要被另外一个apache 1.3 的实例用掉1.4G，所以我们最后可以用于apache2和PHP5的内存只有600M。别的就不能告诉你了
这篇文章分为以下几个主题展开：
- 计算你的需求
- 测试应用的实际性能
- 通用的优化方法
- Apd和PHP配置
- Zend Framework建议
计算你的需求在优化你的应用之前，你应该计算一下应用需要达到多大的吞吐量，比如说，我们的应用需要支持每个月300万的页面访问量，25万独立访问者，然后才开始对峰值性能进行优化。在这个例子中，我们把页面访问量除以28（一个月至少有28天，即当闰年的二月），得到每天是10.8万的访问量，然后再除以24、60和60，最后得到这个应用最少需要这个吞吐量：
3.000.000 / 28 / 24 / 60 / 60 = 1.24 请求/秒
同样的计算可以应用于并发用户：
250.000 / 28 / 24 / 60 / 60 = 0,1 并发用户
当然，这不是实际的最高值，我们需要让应用达到比当前统计更高的性能，让它可以承受更大的流量。现在的首要任务仍然是获取需要达到的最低流量，在访问高峰期（可以查看站点的统计报告得知），访问量必然要高于其他时间，找出这个时间段内的访问量。在我们的项目中，这个时间段是11:00 AM到22:00 PM，所以用11小时代替原来公司中的24小时：
3.000.000 / 28 / 11 / 60 / 60 = 2.7 请求/秒
250.000 / 28 / 11 / 60 / 60 = 0,2 并发用户
这才是你实际要达到的性能要求。因为我们想提供更高的吞吐量，所以我们把目标定的更高，我们的要求是：10 请求/秒和100并发用户。
测试应用的实际性能如你在Till文章中看到的那样，你可以方便地在命令行中使用ApacheBench（ab）对应用进行性能测试，并且要保证是对应用本身的测试，不要有中间层或开启缓存功能。最好的办法是在本地的机器上测试，不过有时候很难有这个条件。
@mathieuk推荐使用
Siege，它可以实现更深入的测试（如多url测试等），或许这个工具能够提供很多帮助。在本文中，我仍然使用ApacheBench，不过以后我肯定会去试用一下Siege这个工具。
对性能测试，我们进行一个简单的测试，获取一个基准结果。即100个并发用户，对首页进行1000次访问：
BASH:
你可以从这个测试中得到很多信息，并确保每次优化代码之后，都运行相同的测试用例，这样可以确定是否已经达到自己的优化目标，事实上，还可以对多次测试的统计数据进行比较，检查优化的效果。你要的数据可能像下面的例子：
- 每秒请求数： 4413.30 [#/sec] (平均值)
或其他你要的数据。
通用的优化方法好，现在开始切入正题。但在此之前，需要你为自己的Web应用做几件简单的事情：
确保已经设置AllowOverride None请在虚拟主机配置或httpd配置中设置ZF的重写规则，否则每次请求都需要解析.htaccess文件。重写规则不应该经常变化，没有必要在每个应用中存在.htaccess文件。(或者通过svn配置虚拟主机和部署应用，这么做非常方便)
确保通过CDN为所有图片提供服务为静态文件设置一个DNS别名是最简单的办法。把图片和CSS等静态文件放置在静态主机上，你可以配置主机名类似为server[1-4].static.*的主机，在同一个服务器上提供这些静态文件服务。客户端浏览器将会非常喜欢这种部署方式（然而如Yahoo所言，不要多于四台CDN服务器）。
可以使用轻量级的Web服务器为静态文件提供服务，如lighttpd、nginx或其它类似服务器，或者配置一个精简版的apache服务器也是可行的。
不要忘记添加缓存和gzip压缩支持。在linux/apache服务器上，我们对静态域使用以下的规则：
APACHE:
安装
Yslow for firebugYahoo提供很多有趣的建议来教你如何优化客户端的代码，这比后端优化要简单很多。
安装
APC (或类似模块)这个模块真的很有用。
切入正题解决上面这些问题之后，现在开始真正进入ZF优化的讨论。我将使用PHP的
apd模块，通过pprofp来测试我们应用的性能。
从APD文档中可知，需要在开始分析的代码行前添加
apd_set_pprofp_trace()调用。在我们的ZF应用中，我们在index.php的第一行就调用该函数。
此后，每次执行这个页面，系统都会把我们需要的数据以一个pprofp跟踪文件的形式保存在硬盘上。通过该文件，可以查看页面的执行情况，这对于页面而言非常有用。你可以以选项-R来调用pprofp，然后得到下面类似的结果：
TEXT: Trace for /webdocs/com.example.www/releases/20081102125639/public/index.php
Total Elapsed Time = 0.99
Total System Time = 0.19
Total User Time = 0.60
- ..............................
通过这个图表，你可以知道哪些方法被频繁调用，哪里可以做一些优化。（你可以通过-n选项查看更多的信息）。另外你可以得到完整应用树的一个完整列表，可以容易的发现哪些代码重复次数最多，这样就可以确定立即优化那些地方。
我们第一次运行pprofp，我们的列表树有229602行。这意味着每次对首页的请求，PHP引擎需要分析和读入229602行代码。几次优化之后，行数降到了36810行，这就好多了，但这花了很多的人力。在分析了这些工作之后，我们整理出以下一些需要牢记的规则。
帖子字数超了，所以把pprofp结果给删除了好多，有兴趣去我的博客看吧：
优化Zend Framework应用(一) 优化Zend Framework应用(二)
