云顶娱乐手机官网-云顶娱乐网址

热门关键词: 云顶娱乐手机官网,云顶娱乐网址

PHP质量优化大全(php.ini)

2019-11-07 作者:云顶娱乐网址   |   浏览(192)

如何正确发布PHP代码

几乎每一个 PHP 程序员都发布过代码,可能是通过 FTP 或者 rsync 同步的,也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码,但是现实却是很少有人注意其中的细节,实际上这里面有好多坑,很可能你就在坑中却浑然不知。

一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话,那么在发布期间,任何一次请求只能在单一状态下被执行。如此称之为支持原子发布;反之如果在发布期间,一次请求跨越不同的状态,那么就不能称之为原子发布。我们不妨举个例子来说明一下:假设一次请求需要 include 两个 PHP 文件,分别是 a.phpb.php,当 include a.php 完成后,发布代码,接着 include b.php,如果处理不当的话,那么就可能会导致旧版本的 a.php 和新版本的 b.php 同时存在于同一个请求之中,换句话说就是没有实现原子发布。

开源世界里有很多不错的发布代码工具,比如 ruby 社区的 capistrano,其流程大致就是发布代码到一个全新的目录,然后再软链接到真正的发布目录。

├── current -> releases/v1
└── releases
    ├── v1
    │   ├── foo.php
    │   └── bar.php
    └── v2
        ├── foo.php
        └── bar.php

不过鉴于 PHP 本身的特殊性,如果只是简单套用上面的流程,那么将很难实现真正的原子发布。要理清个中缘由,还需要了解一下 PHP 中的两个 Cache 的概念:

  • opcode cache
  • realpath cache

先聊聊 opcode cache,基本就是 apc 或者 zend opcode,关于它的作用,大家都已经很熟悉,不必多言,需要注意的是 apc 的 bug 很多,比如开启了 apc.enable_cli 配置后就会有很多灵异问题,所以说 opcode cache 还是尽可能使用 zend opcache 吧,如果需要缓存数据,可以用 apcu。此外 apczend opcode 对缓存键的选择有所差异:apc 选择的是文件的 inodezend opcode 选择的是文件的 path

再聊聊 realpath cache,它的作用是缓冲获取文件信息的 IO 操作,大多数时候它对我们而言是透明的,以至于很多人都不知道它的存在,需要注意的是 realpath cache 是进程级别的,也就是说,每一个 php-fpm 进程都有自己独立的 realpath cache

假设在发布代码期间,opcode cache 或者 realpath cache 里的数据出现过期,那么就会出现一部分缓存是旧文件,一部分缓存是新文件的非原子发布的情况,为了避免出现这种情况,我们应该保证缓存过期时间足够长,最好是除非我们手动刷新,否则永远不过期,对应到配置上就是:关闭 apc.stat、opcache.validate_timestamps 配置,设置足够大的 realpath_cache_size、realpath_cache_ttl 配置,必要的监控总是有好处的。

相关的技术细节特别琐碎,建议大家仔细阅读如下资料:

  • realpath_cache
  • PHP’s OPCache extension review
  • Atomic deploys at Etsy
  • Cache invalidation for scripts in symlinked folders

在采用软链接发布代码的时候,通常遇到的第一个问题多半是新代码不生效!即便调用了 apc_clear_cache 或者 opcache_reset 方法也无效,重启 php-fpm 自然是能够解决问题,不过对脚本语言来说重启太重了!难道除了重启就没有别的办法了么?

事实上之所以会出现这样的问题,主要是因为 opcode cache 是通过 realpath cache 获取文件信息,即便软链接已经指向了新位置,但是如果 realpath cache 里还保存着旧数据的话,opcode cache 依然无法知道新代码的存在,缺省情况下,realpath_cache_ttl 缓存有效期是两分钟,这意味着发布代码后,可能要两分钟才能生效。为了让发布尽快生效,需要以进程为单位清除 realpath cache

<?php

    $key = 'php.pid_' . getmypid();

    if (($rev = apc_fetch($key)) != DEPLOY_VERSION) {
        if($rev < DEPLOY_VERSION) {
            apc_store($key, DEPLOY_VERSION);
        }

        clearstatcache(true);
    }

如此在 apc 环境下基本就能工作了,但是在 zend opcode 环境下还可能有问题。因为在缺省情况下 opcache.revalidate_path 是关闭的,此时会缓存未解析的符号链接的值,这会导致即便软链接指向修改了,也无法生效,所以在使用 zend opcode 的时候,如果使用了软链接,视情况可能需要把 opcache.revalidate_path 激活。

详细介绍参考:PHP’s OPCache extension review。

BTW:如果需要手动重置 opcode cache,需要注意的是因为它是基于 SAPI 的概念,所以不能直接在命令行下调用 apc_clear_cache 或者 opcache_reset 方法来重置缓存,当然办法总是有的,那就是使用 CacheTool 在命令行下模拟 fastcgi 请求。

分析到这里,我们不妨反思一下:在 PHP 中原子发布之所以是一个棘手的问题,归根结底是因为软链接和缓存之间的的矛盾。不管是 opcode cache 还是 realpath cache,都是 PHP 固有的缓存特性,基于客观需要无法绕开,如此说来是否有办法绕开软链接,使其成为马奇诺防线呢?答案是 NGINX 的 $realpath_root:

    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT $realpath_root;

有了 $realpath_root,即便 DOCUMENT_ROOT 目录中含有软链接,NGINX 也会把软链接指向的真正的路径发给 PHP,也就是说,对 PHP 而言,软链接已经不存在了!不过作为代价,每一次请求,NGINX 都要通过相对昂贵的 IO 操作获取 $realpath_root 的值,通过 strace 命令我们能监控这一过程,下图从 currentfoo 的过程:

在本例中,压测发现使用 $realpath_root 后,性能下降了大约 5% 左右,不过明眼人一下就能发现,虽然 $realpath_root 导致了 lstatreadlink 操作,但是 lstat 操作的次数是和目录深度成正比的,也就是说目录越深,执行的 lstat 次数越多,性能下降也就越大。如果能够降低发布目录的深度,那么可以预计还能降低一些性能损耗。

结尾介绍一下 Deployer,它是 PHP 中做得比较好的工具,有很多特色,比如支持并行发布,具体演示如下图,左边是串行,右边是并行,使用「vvv」能得到更详细信息:

不过 Deployer 在原子发布上有一点瑕疵,具体见 release/symlink 代码:

<?php

// deploy:release
run("cd {{deploy_path}} && if [ -h release ]; then rm release; fi");
run("ln -s $releasePath {{deploy_path}}/release");
// deploy:symlink
run("cd {{deploy_path}} && ln -sfn {{release_path}} current");
run("cd {{deploy_path}} && rm release");

?>

release 的时候,它是先删除再创建,是一个两步的非原子操作,在 symlink 的时候,看上去「ln -sfn」是单步原子操作,实际上也是错误的:

shell> strace ln -sfn releases/foo current
symlink("releases/foo", "current")      = -1 EEXIST (File exists)
unlink("current")                       = 0
symlink("releases/foo", "current")      = 0

通过 strace 我们能清晰的看到,虽然表面上使用「ln -sfn」是一步操作,但是内部依然是按照先删除再创建的逻辑执行的,实际上这里应该搭配使用「ln & mv」

shell> ln -sfn releases/foo current.tmp
shell> mv -fT current.tmp current

先通过 ln 创建一个临时的软链接,再通过 mv 实现原子操作,此时如果使用 strace 监控,会发现 mv「T」 选项实际上仅仅执行了一个 rename 操作,所以是原子的。

BTW:在使用「ln -sfn」前后,如果使用 stat 查看新旧文件的 inode 的话,可能会发现它们拥有一样的 inode 值,看上去和我们的结论相悖,其实不然,实际上只是复用删除值而已(如果想验证,注意 Linux 会复用,Mac 不会复用)。

据说一千个人的心中就有一千个哈姆雷特,不过我希望所有的 PHP 程序员在发布 PHP 代码的时候都能采用一种方法,那就是本文介绍的方法,正确的方法。

原文转自老王的火丁笔记,原文地址:如何正确发布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以上版本能够很好地解决这个问题。
解决方法:

[ PHP ] 如何正确发布 PHP 代码,php发布代码

复制代码 代码如下:

在这个过程中,有几点是需要注意的:

    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
    RewriteRule .* %{DOCUMENT_ROOT}%/index.php
   #RewriteRule .* /index.php

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.  apache2ctl -X &
使用-X(debug)参数启动httpd进程,这个时候只启动1个httpd进程

 
第三章  提高PHP性能的编码技巧

您可能感兴趣的文章:

  • PHP生成器简单实例
  • PHP新特性详解之命名空间、性状与生成器
  • 50个PHP程序性能优化的方法
  • 分享五个PHP7性能优化提升技巧
  • PHP性能优化 产生高度优化代码
  • 有关PHP性能优化的介绍
  • PHP中你可能忽略的性能优化利器:生成器

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

那些地方可以优化呢?

第一章  针对系统调用过多的优化
我这次的优化针对syscall调用过多的问题,所以使用strace跟踪apache进行分析。

一般可以看到很多这类信息:
stat64("/error/dir/test.php", 0xbfab4b9c) = -1 ENOENT (No such file or directory)
解决方法:
1. 在应用php里面设置include_path,去掉'.'等相对路径,将其中包含使用文件比较多的目录放到前面。保证遍历include_path的时候能够很快找到。

  1. ps -ef | grep httpd
    找到需要strace的pid
  2. strace -p $PID -o /tmp/strace.log
    发送一个http请求到httpd,就能看到strace信息了。
     
    一、include_path问题

 
第二章  使用APC缓存

  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文件。这个是很耗性能的,推荐关掉。
    解决方法:
  4. 设定apc.stat=0,不必每次请求都访问需要用到的php文件。
    需要注意的是:每次发版本改动了php文件的时候,必须调用apc_clear()清除apc缓存,否则你的代码永远也不会生效。
    六、smarty调优
    对于模块化比较好,而且应用比较多的网站,如果使用了smarty模板系统,这个时候就需要对smarty进行调优了,否则smarty部分的开销就很可观。之前根据一个经验来看,smarty可以占到10%左右的开销。
    默认配置下,smarty对检测每个模板文件是否有更新,决定是否重新编译模板文件。如果模板文件比较多,则会多出很多stat系统调用,加上context switch,开销会不小。
    解决方法:
  5. $smarty->compile_check = false;
    去掉每次的检测,但是这样之后,每次发版本都要把compile_dir目录的已编译模板删除,否则你的模板文件永远也不会生效了。
  6. 如果可能,可以使用cache功能。
     
    结论
    经过上面的调优,结论如下:
    1.          升级到php5.3.1开启上面的优化,比5.2.3性能高10%以上
    2.          在优化配置下,使用Zend Framework开发的一个搜索应用,每秒请求可达210/rps
    3.          在优化配置下,使用doophp framework开发的一个搜索应用,每秒请求可达450/rps

4、注意:
Apc与apache的进程共享内存,所以只有在执行apache进程时,才可以往apc中存值,普通的php进程不能访问apc共享内存。

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()掉;

  1. 使用绝对路径进行include,require,include_once,require_once
  2. 使用php的自动加载机制
     
    二、apache的rewrite配置

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 官方网站为

本文由云顶娱乐手机官网发布于云顶娱乐网址,转载请注明出处:PHP质量优化大全(php.ini)

关键词: