一次php应用的优化实践

转载自:

http://blog.webshuo.com/2011/04/06/一次php应用的优化实践/

这种发现问题,解决问题的思路和方法值得学习!

之前做过的一次优化实践,最近翻出来看看,有些通用的优化手段还是可以复用的。系统跑得时间长了,总会出现这样那样的问题和瓶颈,有了问题不可怕,我们有“打虎”的家伙事儿--无非就是定位问题->分析问题->提出解决方案->实践->结果反馈->总结再优化。

问题描述:系统采用 PHP5 + Zend framework 开发,在数据规模和访问量增加后(千万级),出现了后台apache服务器负载过高的现象,在访问高峰时段(比如每天下班到晚上10点这一段时间,特别是周五),机器CPU负载会飙升到170多,CPU负载过高造成处理请求也相应的变慢,所以亟需解决这个问题。

问题分析:通过连续几天的观察和分析,当CPU使用率达到100%时,其中系统CPU使用率占据了很大的比例,用户CPU使用率倒不是很高,另外前端 haproxy 和 squid cache的cpu负载很低,memcached和squid的hit ratio一般都能达到60%左右。

分析backend的access-log,发现相当大一部分请求的User-Agent是搜索爬虫;

同时,在 apache 上配置了xdebug,在空闲时段对主要的页面的测量了一组性能数据,通过使用kcachegrind对测得的数据进行分析(如何配置xdebug,可以用soso搜一下),发现:
性能数据不够稳定,同样的请求之间测试数据会相差比较大
慢的点比较分散
memcached的访问大部分的情况都比较慢(100ms以上)

解决方案通过上述初步的分析,对现有的程序逐步作了一系列调整。

首先考虑到的是是否可以想办法增加前端squid cache的Hit ratio,从而减少穿透squid到达后端apache的请求数。

考虑到相当一部分请求来源于Crawler,而之前squid cache只会对设置了language cookie的请求作cache,而来自Crawler的请求都没有cookie信息。于是想到把来自Crawler的请求都默认为language为zh_CN的,然后修改haproxy的配置,把User-Agent为常见的Crawler的请求都转交给squid cache.

修改php代码,把一些页面的缓存时间设置得更长一些

经过如上两个步骤,到达apache的请求确实减少了一些,但是这个对cpu负载过高的问题帮助很少,于是另寻它法。

其次,根据使用 xdebug profiling的结果来看,和memcached的交互耗时比较长,于是想是否可以想办法让memcached能更快地响应请求,从而使得每一次请求能更快完成,从而使并发降低。

通过代码分析,发现线上memcached使用的是poll(),而memcached的连接数在繁忙的时候保持在1000左右,memcached的CPU使用率在 30% 左右。很显然,poll()方式在处理如此多的并发连接时是很低效的。于是重新编译memcached,使其使用epoll()的方式来处理请求,替换为epoll之后,memcached的cpu usage从 30%左右降低到 3% 左右,10倍之多!

另外,memcached的hit ratio不是特别高,而且被换出的item数也比较高,于是想到对cache的内容作partition.原本打算做 manually partition,后来发现php的最新的memcache扩展就能支持根据cache的key自动作partition,而且能在不修改程序代码(需要修改配置文件:-))的情况下增加新的memcached实例。于是升级每一个apache的php memcache扩展,然后再配置文件中增加了一台新的memcached。到此完成memcached的内容partition。修改之后的效果比较显著,页面的载入时间比修改前缩短了很多。

经过这两步的调整,memcached的效率比以前高了,但是apache的负载仍然居高不下,没辙,再想其它办法!

进一步深入分析前面说到主要系统CPU占用很高,要找原因只能深入内核了:) 从现在开始了我们的strace之旅。套用一句Nike的广告词:Just strace it!

在高峰时段对 httpd 进程进行了strace,方法不外乎如下这些

strace -p PID -c 得出 summary
strace -p PID -o output.log 写入文件,慢慢研究
strace -p PID -e trace=file 只看 filesystem 操作相关的 syscalls
strace -p PID -elstat64,stat64,open,getcwd 只跟踪这些 syscalls

从上述strace分析得到如下结论:

lstat64,stat64,open等 syscalls实在是多啊
上述 syscalls 占用时间确实不少! 60%以上的时间都被它们抢了, orz
绝大多数 syscall 是失败的,真是屡败屡战啊

有了上述数据,我们就找到了问题的方向了,那就是找这些毫无意义的系统调用是怎么来的。

经过分析,这些是php要加载某一个类时,会去 include_path 中定义的一系列目录中搜寻该类对应的文件,挨个目录这么试过去,直到找到为止。嗯,这种方式显然是比较低效的,有没有更好的方式来完成这个事情呢?答案是肯定的,有!而且还有不止一种方法!

调用require_once()时,参数写绝对路径(开始Guys write Zend Framework就不懂这个道理;后来才有更新))

使用 __autoload()对class进行 lazy loading,也就是说真正需要的时候才去加载,而不是不管三七二十一把可能用到的类文件都require_once了。

问题是找到了,但是要解决这个问题还面临着另一个问题。开发中代码都注意用绝对路径了,唯一可以改进的地方是改为 lazy loading,但是 Zend Framework中大量的require_once采用相对路径,这个就是导致问题——这里我说的问题是本文我们谈论的CPU负载过高的问题——的根本原因。

OK,既然问题找到了,动手解决。写个脚本自动生成 Class -> File Path 对应关系,生成代码中所有类和Zend Framework中所有类的对应关系文件。把代码中和Zend Framework库中所有的 require_once 都注释掉。然后进行详细的测试,然后上线。结果令人吃惊,负载降到了 3 以内!!问题解决。

总结:

写代码的人都知道,可能出问题的地方总会出问题,任何问题都会有个原因(哪怕暂时没有找到),从根上解决才是王道,解决什么问题不重要,希望大家能学习这个解决的思路,善于利用工具。ok,这个case就这样了。