针对系统调用过多的优化
我这次的优化针对 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", 0xbfab4b<?xml:namespace prefix = st1 />9c) = -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() 问题
大家可以看一下这篇文章： http://bugs.php.net/bug.php?id=43864
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
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 官方网站为 http://pecl.php.net/package/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 、当你需要时，你总能把代码分解成方法。