优化Zend Framework应用.docVIP

来到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: ab -n?1000?-c?100?/(不要忘记url末尾的斜杠) 你可以从这个测试中得到很多信息，并确保每次优化代码之后，都运行相同的测试用例，这样可以确定是否已经达到自己的优化目标，事实上，还可以对多次测试的统计数据进行比较，检查优化的效果。你要的数据可能像下面的例子： 每秒请求数：?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: # Also see: /performance/rules.html#gzip Ad