PHP性能优化大全(php.ini)
第一章 针对系统调用过多的优化
我这次的优化针对syscall调用过多的问题，所以使用strace跟踪apache进行分析。
1. apache2ctl -x &
使用-x(debug)参数启动httpd进程，这个时候只启动1个httpd进程
2. ps -ef | grep httpd
找到需要strace的pid
3. strace -p $pid -o /tmp/strace.log
发送一个http请求到httpd，就能看到strace信息了。
一、include_path问题
一般可以看到很多这类信息：
stat64("/error/dir/test.php", 0xbfab4b9c) = -1 enoent (no such file or directory)
解决方法：
1. 在应用php里面设置include_path，去掉'.'等相对路径，将其中包含使用文件比较多的目录放到前面。保证遍历include_path的时候能够很快找到。
2. 使用绝对路径进行include，require，include_once，require_once
3. 使用php的自动加载机制
二、apache的rewrite配置
rewriteengine on
rewritecond %{document_root}%{request_filename} !-f
rewritecond %{document_root}%{request_filename} !-d
rewriterule .* %{document_root}%/index.php
#rewriterule .* /index.php
这里最后一个注释掉的rewrite配置不好，因为它每次请求都会多一次syscall
stat64("/index.php", 0xbfab4b9c) = -1 enoent (no such file or directory)
三、apache日志问题
我们在测试一个问题的时候，发现如果自定义日志里面记录了访问时间等信息，会多出很多
stat64("/etc/localtime", {st_mode=s_ifreg|0644, st_size=165, ...}) = 0
如果记录的日志比较多，性能下降非常严重，对于简单应用，记录复杂日志，性能会下降30倍。
解决方法：
在多个apache前端架http层的proxy，如haproxy，nginx。在这些地方记录日志。接入层负载一般不高，所以proxy可以做一些记录日志的工作。在这种配置下，可以关闭apache的日志。
四、realpath()问题
大家可以看一下这篇文章：
lstat64调用多了之后，主机cpu和io都会比较高。
究其原因，因为php5.2.x对realpath()的实现不够好，导致会针对目录层次，逐级调用lstat64()。
为了解决这个问题，它使用了realpath_cache，针对某个文件，存储其realpath。这里只存储了叶子节点的realpath，而对 路径上的内容没有存储，所以在做"/a/b/c/d/e/f/g/a.php"realpath检查的时候逐级调用lstat64，而在做"/a/b/c /d/e/f/g/b.php"检查的时候，还要对""/a/b/c/d/e/f/g/"做逐级检查。所以有些优化建议就是"减少目录层次，甚至放到"/"根目录下"。当然我不推荐这么干。从5.3.0开始，php对realpath()做了高效的实现，路realpath的中间路径也做了缓存，以上面的情况为例，检查"/a/b/c/d/e/f/g/b.php"的时候就只会做"b.php"的检查了。所以，升级到php5.3.0以上版本能够很好地解决这个问题。
解决方法：
1. 尽量少用include_once和require_once
因为这两个函数会做realpath检查，防止有符号链接的情况导致重复加载。不用它们就能减少realpath的调用。
2. 合理设定php.ini中的realpath_cache_size和realpath_cache_ttl参数
既然使用了realpath_cache，那肯定有大小限制。对于使用了很多文件，比如用了zend framework的项目，可能默认realpath_cache_size=16k就太小了，需要增大这个设置，推荐设置为256k以上。另外默认realpath_cache_ttl=120，2分钟就过时了，怎么也要设定为3600（1小时）。
这里需要注意的是，这个realpath_cache是每隔apache进程独占的，所以很吃内存的，不能设置的太大。
3. 升级到php5.3.x
没什么好说的，如果应用经过详细测试没有问题，那么推荐升级到高版本。
五、apc的使用
apc能够缓存php的opcode码，能普遍提升30%的性能。但是默认apc.stat=1，这样每次请求都会访问需要使用的php文件，看看这个文件是否更新了，已决定是否重新编译php文件。这个是很耗性能的，推荐关掉。
解决方法：
1. 设定apc.stat=0，不必每次请求都访问需要用到的php文件。
需要注意的是：每次发版本改动了php文件的时候，必须调用apc_clear()清除apc缓存，否则你的代码永远也不会生效。
六、smarty调优
对于模块化比较好，而且应用比较多的网站，如果使用了smarty模板系统，这个时候就需要对smarty进行调优了，否则smarty部分的开销就很可观。之前根据一个经验来看，smarty可以占到10%左右的开销。
默认配置下，smarty对检测每个模板文件是否有更新，决定是否重新编译模板文件。如果模板文件比较多，则会多出很多stat系统调用，加上context switch，开销会不小。
解决方法：
1. $smarty->compile_check = false;
去掉每次的检测，但是这样之后，每次发版本都要把compile_dir目录的已编译模板删除，否则你的模板文件永远也不会生效了。
2. 如果可能，可以使用cache功能。
结论
经过上面的调优，结论如下：
1. 升级到php5.3.1开启上面的优化，比5.2.3性能高10%以上
2. 在优化配置下，使用zend framework开发的一个搜索应用，每秒请求可达210/rps
3. 在优化配置下，使用doophp framework开发的一个搜索应用，每秒请求可达450/rps
第二章 使用apc缓存
php程序的执行流程
—》客户端（浏览器）请求get hello.php
—-》cgi服务器接（譬如apache）收到请求，根据配置寻找php的处理程序（譬如mod_php）
—-》apache加载php的处理程序，php的处理程序读取php.ini初始化php的解释环境
—-》mod_php定位寻找hell.php，将其载入到内存中来
—-》mod_php编译源代码成为opcode树
—-》mod_php执行opcode树
—-》生成结果给浏览器
在这个过程中，有几点是需要注意的：
1、 对许多代码文件说，特别是含有很多包含文件（include or require）。它们需要花费更多的时间和解析并产生中间代码。
2、 即使php代码文件没有发生改变，这个执行过程还会严格的按照流程执行。也就是说，无论你的应该程序是否发生改变，每次调用的时候，都需要重新编译生成opcode码。（其实这就是编译缓存存在的理由）
3、 这个流程不仅仅发生在主要的代码文件，对于每一次的include和require来说，都会执行这个流程。（这是可以继续优化的）
那些地方可以优化呢？
1、将mod_php fast-cgi化，避免每次都要加载这个模块，这个模块还要每次都去初始化php的解释环境。
2、缓存php文件的opcode码，这样话，避免每次都去编译。
apc可用用来实现第2点。编译缓存去掉了执行php过程中的解析过程，所以它对含有大量php代码的应用程序是非常有效的。通常情况下可以提升2-3倍以上的速度。对于包含大量include文件的项目，编译缓存更现实出它的优越性。
注：include并不会被编译缓存进行缓存。比如现在有两个文件：main.php 和tobeinclude.php，其中main.php中有这样的语句include tobeinclude.php'。假设中间码的后缀为.op(实际上不是这样)。那么加上缓存cache后 main.php=>main.op ，tobeinclude.php=>tobeinclude.op。但是php在执行main.php的时候，她还是需要去解析main.op中的include命令，去调用tobeinclude.op的内容。具体流程是这样的。
…=>执行main.op=>执行tobeinclude.op=>…
而不是之间简单的执行main.op
所以说"过多的include文件会降低程序性能的"。
apc的具体配置。
alternative php cache（apc）是 php 的一个免费公开的优化代码缓存。它用来提供免费，公开并且强健的架构来缓存和优化 php 的中间代码。
apc 官方网站为
1、安装
以php extension 形式安装
phpize
./configure --enable-apc --enable-apc-mmap
make
make install
生成.so，将.so拷贝到php引用modules的目录下，修改权限755
2、配置
apc.enabled boolean
apc.optimization optimization
选项在脚本中可以改变
apc php.ini配置选项详解
[apc]
; alternative php cache 用于缓存和优化php中间代码
apc.cache_by_default = on
;sys
; 是否默认对所有文件启用缓冲。
; 若设为off并与以加号开头的apc.filters指令一起用，则文件仅在匹配过滤器时才被缓存。
apc.enable_cli = off
;sys
; 是否为cli版本启用apc功能，仅用于测试和调试目的才打开此指令。
apc.enabled = on
; 是否启用apc，如果apc被静态编译进php又想禁用它，这是唯一的办法。
apc.file_update_protection = 2
;sys
; 当你在一个运行中的服务器上修改文件时，你应当执行原子操作。
; 也就是先写进一个临时文件，然后将该文件重命名(mv)到最终的名字。
; 文本编辑器以及 cp, tar 等程序却并不是这样操作的，从而导致有可能缓冲了残缺的文件。
; 默认值 2 表示在访问文件时如果发现修改时间距离访问时间小于 2 秒则不做缓冲。
; 那个不幸的访问者可能得到残缺的内容，但是这种坏影响却不会通过缓存扩大化。
; 如果你能确保所有的更新操作都是原子操作，那么可以用 0 关闭此特性。
; 如果你的系统由于大量的io操作导致更新缓慢，你就需要增大此值。
apc.filters =
;sys
; 一个以逗号分隔的posix扩展正则表达式列表。
; 如果源文件名与任意一个模式匹配，则该文件不被缓存。
; 注意，用来匹配的文件名是传递给include/require的文件名，而不是绝对路径。
; 如果正则表达式的第一个字符是"+"则意味着任何匹配表达式的文件会被缓存，
; 如果第一个字符是"-"则任何匹配项都不会被缓存。"-"是默认值，可以省略掉。
apc.ttl = 0
;sys
; 缓存条目在缓冲区中允许逗留的秒数。0 表示永不超时。建议值为7200~36000。
; 设为 0 意味着缓冲区有可能被旧的缓存条目填满，从而导致无法缓存新条目。
apc.user_ttl = 0
;sys
; 类似于apc.ttl，只是针对每个用户而言，建议值为7200~36000。
; 设为 0 意味着缓冲区有可能被旧的缓存条目填满，从而导致无法缓存新条目。
apc.gc_ttl = 3600
;sys
; 缓存条目在垃圾回收表中能够存在的秒数。
; 此值提供了一个安全措施，即使一个服务器进程在执行缓存的源文件时崩溃，
; 而且该源文件已经被修改，为旧版本分配的内存也不会被回收，直到达到此ttl值为止。
; 设为零将禁用此特性。
apc.include_once_override = off
;sys
; 请保持为off，否则可能导致意想不到的结果。
apc.max_file_size = 1m
;sys
; 禁止大于此尺寸的文件被缓存。
apc.mmap_file_mask =
;sys
; 如果使用–enable-mmap(默认启用)为apc编译了mmap支持，
; 这里的值就是传递给mmap模块的mktemp风格的文件掩码(建议值为"/tmp/apc.xxxxxx")。
; 该掩码用于决定内存映射区域是否要被file-backed或者shared memory backed。
; 对于直接的file-backed内存映射，要设置成"/tmp/apc.xxxxxx"的样子(恰好6个x)。
; 要使用posix风格的shm_open/mmap就需要设置成"/apc.shm.xxxxxx"的样子。
; 你还可以设为"/dev/zero"来为匿名映射的内存使用内核的"/dev/zero"接口。
; 不定义此指令则表示强制使用匿名映射。
apc.num_files_hint = 1000
;sys
; web服务器上可能被包含或被请求的不同源文件的大致数量(建议值为1024~4096)。
; 如果你不能确定，则设为 0 ；此设定主要用于拥有数千个源文件的站点。
apc.optimization = 0
; 优化级别(建议值为 0 ) 。
; 正整数值表示启用优化器，值越高则使用越激进的优化。
; 更高的值可能有非常有限的速度提升，但目前尚在试验中。
apc.report_autofilter = off
;sys
; 是否记录所有由于early/late binding原因而自动未被缓存的脚本。
apc.shm_segments = 1
;sys
; 为编译器缓冲区分配的共享内存块数量(建议值为1)。
; 如果apc耗尽了共享内存，并且已将apc.shm_size指令设为系统允许的最大值，
; 你可以尝试增大此值。
apc.shm_size = 30
;sys
; 每个共享内存块的大小(以mb为单位，建议值为128~256)。
; 有些系统(包括大多数bsd变种)默认的共享内存块大小非常少。
apc.slam_defense = 0
;sys(反对使用该指令，建议该用apc.write_lock指令)
; 在非常繁忙的服务器上，无论是启动服务还是修改文件，
; 都可能由于多个进程企图同时缓存一个文件而导致竞争条件。
; 这个指令用于设置进程在处理未被缓存的文件时跳过缓存步骤的百分率。
; 比如设为75表示在遇到未被缓存的文件时有75%的概率不进行缓存，从而减少碰撞几率。
; 鼓励设为 0 来禁用这个特性。
apc.stat = on
;sys
; 是否启用脚本更新检查。
; 改变这个指令值要非常小心。
; 默认值 on 表示apc在每次请求脚本时都检查脚本是否被更新，
; 如果被更新则自动重新编译和缓存编译后的内容。但这样做对性能有不利影响。
; 如果设为off 则表示不进行检查，从而使性能得到大幅提高。
; 但是为了使更新的内容生效，你必须重启web服务器。
; 这个指令对于include/require的文件同样有效。但是需要注意的是，
; 如果你使用的是相对路径，apc就必须在每一次include/require时都进行检查以定位文件。
; 而使用绝对路径则可以跳过检查，所以鼓励你使用绝对路径进行include/require操作。
apc.user_entries_hint = 100
;sys
; 类似于num_files_hint指令，只是针对每个不同用户而言。
; 如果你不能确定，则设为 0 。
apc.write_lock = on
;sys
; 是否启用写入锁。
; 在非常繁忙的服务器上，无论是启动服务还是修改文件，
; 都可能由于多个进程企图同时缓存一个文件而导致竞争条件。
; 启用该指令可以避免竞争条件的出现。
apc.rfc1867 = off
;sys
; 打开该指令后，对于每个恰好在file字段之前含有apc_upload_progress字段的上传文件，apc都将自动创建一个upload_的用户缓存条目(就是apc_upload_progress字段值)。
3、php函数
apc_cache_info - retrieves cached information (and meta-data) from apc's data store
apc_clear_cache - clears the apc cache
apc_define_constants - defines a set of constants for later retrieval and mass-definition
apc_delete - removes a stored variable from the cache
apc_fetch - fetch a stored variable from the cache
apc_load_constants - loads a set of constants from the cache
apc_sma_info - retrieves apc's shared memory allocation information
apc_store - cache a variable in the data store
4、注意：
apc与apache的进程共享内存，所以只有在执行apache进程时，才可以往apc中存值，普通的php进程不能访问apc共享内存。
第三章 提高php性能的编码技巧
0、用单引号代替双引号来包含字符串，这样做会更快一些。因为php会在双引号包围的字符串中搜寻变量，单引号则不会，注意：只有echo能这么做，它是一种可以把多个字符串当作参数的"函数"（译注：php手册中说echo是语言结构，不是真正的函数，故把函数加上了双引号）。
1、如果能将类的方法定义成static，就尽量定义成static，它的速度会提升将近4倍。
2、$row['id'] 的速度是$row[id]的7倍。
3、echo 比print 快，并且使用echo的多重参数（译注：指用逗号而不是句点）代替字符串连接，比如echo $str1,$str2。
4、在执行for循环之前确定最大循环数，不要每循环一次都计算最大值，最好运用foreach代替。
5、注销那些不用的变量尤其是大数组，以便释放内存。
6、尽量避免使用__get，__set，__autoload。
7、require_once()代价昂贵。
8、include文件时尽量使用绝对路径，因为它避免了php去include_path里查找文件的速度，解析操作系统路径所需的时间会更少。
9、如果你想知道脚本开始执行（译注：即服务器端收到客户端请求）的时刻，使用$_server[‘request_time']要好于time()。
10、函数代替正则表达式完成相同功能。
11、str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。
12、如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。
13、使用选择分支语句（译注：即switch case）好于使用多个if，else if语句。
14、用@屏蔽错误消息的做法非常低效，极其低效。
15、打开apache的mod_deflate模块，可以提高网页的浏览速度。
16、数据库连接当使用完毕时应关掉，不要用长连接。
17、错误消息代价昂贵。
18、在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。
19、递增一个全局变量要比递增一个局部变量慢2倍。
20、递增一个对象属性（如：$this->prop++）要比递增一个局部变量慢3倍。
21、递增一个未预定义的局部变量要比递增一个预定义的局部变量慢9至10倍。
22、仅定义一个局部变量而没在函数中调用它，同样会减慢速度（其程度相当于递增一个局部变量）。php大概会检查看是否存在全局变量。
23、方法调用看来与类中定义的方法的数量无关，因为我（在测试方法之前和之后都）添加了10个方法，但性能上没有变化。
24、派生类中的方法运行起来要快于在基类中定义的同样的方法。
25、调用带有一个参数的空函数，其花费的时间相当于执行7至8次的局部变量递增操作。类似的方法调用所花费的时间接近于15次的局部变量递增操作。
26、apache解析一个php脚本的时间要比解析一个静态html页面慢2至10倍。尽量多用静态html页面，少用脚本。
27、除非脚本可以缓存，否则每次调用时都会重新编译一次。引入一套php缓存机制通常可以提升25%至100%的性能，以免除编译开销。
28、尽量做缓存，可使用memcached。memcached是一款高性能的内存对象缓存系统，可用来加速动态web应用程序，减轻数据库负载。对运算码(op code)的缓存很有用，使得脚本不必为每个请求做重新编译。
29、当操作字符串并需要检验其长度是否满足某种要求时，你想当然地会使用strlen()函数。此函数执行起来相当快，因为它不做任何计算，只返回在zval 结构（c的内置数据结构，用于存储php变量）中存储的已知字符串长度。但是，由于strlen()是函数，多多少少会有些慢，因为函数调用会经过诸多步骤，如字母小写化（译注：指函数名小写化，php不区分函数名大小写）、哈希查找，会跟随被调用的函数一起执行。在某些情况下，你可以使用isset() 技巧加速执行你的代码。
（举例如下）
if (strlen($foo) < 5) { echo "foo is too short"$$ }
（与下面的技巧做比较）
if (!isset($foo{5})) { echo "foo is too short"$$ }
调用isset()恰巧比strlen()快，因为与后者不同的是，isset()作为一种语言结构，意味着它的执行不需要函数查找和字母小写化。也就是说，实际上在检验字符串长度的顶层代码中你没有花太多开销。
34、当执行变量$i的递增或递减时，$i++会比++$i慢一些。这种差异是php特有的，并不适用于其他语言，所以请不要修改你的c或java代码并指望它们能立即变快，没用的。++$i更快是因为它只需要3条指令(opcodes)，$i++ 则需要4条指令。后置递增实际上会产生一个临时变量，这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的一种，正如zend的php 优化器所作的那样。牢记这个优化处理不失为一个好主意，因为并不是所有的指令优化器都会做同样的优化处理，并且存在大量没有装配指令优化器的互联网服务提供商（isps）和服务器。
35、并不是事必面向对象(oop)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。
36、并非要用类实现所有的数据结构，数组也很有用。
37、不要把方法细分得过多，仔细想想你真正打算重用的是哪些代码？
38、当你需要时，你总能把代码分解成方法。
39、尽量采用大量的php 内置函数。
40、如果在代码中存在大量耗时的函数，你可以考虑用c扩展的方式实现它们。
41、评估检验(profile)你的代码。检验器会告诉你，代码的哪些部分消耗了多少时间。xdebug调试器包含了检验程序，评估检验总体上可以显示出代码的瓶颈。
42、mod_zip可作为apache模块，用来即时压缩你的数据，并可让数据传输量降低80%。
43、在可以用file_get_contents替代file、fopen、feof、fgets等系列方法的情况下，尽量用file_get_contents，因为他的效率高得多！但是要注意file_get_contents在打开一个url文件时候的php版本问题；
44、尽量的少进行文件操作，虽然php的文件操作效率也不低的；
45、优化select sql语句，在可能的情况下尽量少的进行insert、update操作；
46、尽可能的使用php内部函数（但是我却为了找个php里面不存在的函数，浪费了本可以写出一个自定义函数的时间，经验问题啊！）；
47、循环内部不要**变量，尤其是大变量：对象(这好像不只是php里面要注意的问题吧？)；
48、多维数组尽量不要循环嵌套赋值；
49、在可以用php内部字符串操作函数的情况下，不要用正则表达式；
50、foreach效率更高，尽量用foreach代替while和for循环；
51、用单引号替代双引号引用字符串；
52、"用i+=1代替i=i+1。符合c/c++的习惯，效率还高"；
53、对global变量，应该用完就unset()掉；