欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

一次php应用的优化实践_PHP教程

程序员文章站 2022-06-14 15:00:06
...
之前做过的一次优化实践,最近翻出来看看,有些通用的优化手段还是可以复用的。系统跑得时间长了,总会出现这样那样的问题和瓶颈,有了问题不可怕,我们有“打虎”的家伙事儿--无非就是定位问题->分析问题->提出解决方案->实践->结果反馈->总结再优化。
问题描述:系统采用 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就这样了。

www.bkjia.comtruehttp://www.bkjia.com/PHPjc/478024.htmlTechArticle之前做过的一次优化实践,最近翻出来看看,有些通用的优化手段还是可以复用的。系统跑得时间长了,总会出现这样那样的问题和瓶颈,...