apc定义:apc是一个开放自由的php opcode缓存。它的目标是提供一个自由、开放和健全的框架,用于缓存和优化php中间代码。
一、apc常用函数:
1.apc_clear_cache() 清楚apc缓存内容
2.apc_define_constants(string key,array constants,[,bool case_sensitive]) 将数组constants以常量加入缓存
3.apc_load_constants(string key) 取出常量缓存
4.apc_store(string key,mixed var [, int ttl]) 在缓存中保存数据
5.apc_fetch(string key) 获取apc_store保存的缓存数据
6.apc_delete(string key) 删除apc_store保存的内容
7.apc_add(string key,mixd var [, int ttl]) 缓存一个变量到数据存储(只在变量之前没有被存储的情况)
8.apc_exists(mix keys) 检查是否有一个或者多个apc键名存在
9.apc_delete_file(mixed keys) 从opcode缓存中删除给定文件的缓存
10.apc_compile_file(string filename [,bool atmic=true]) 绕过filters的限制,缓存文件
11.apc_cache_info(string cache_type [,bool limited=false]) 获取缓存i型奶昔
注:apc_clear_cache只清除opcode缓存文件,apc_delete清楚缓存中的变量;预定义变量,可以使用apc_define_constants函数;php变量可以使用函数apc_store,使用apc比memcache会更好,不需要经过网络传输协议tcp;apc不适用于通过函数apc_store缓存频繁变更的用户数据,会出现一些奇异的现象;apc本身不支持分布式。
二、apc常用配置:
1.多少内存将被分配给apc,ini选项apc.shm_size(integer)控制这个设置。默认为30M
2.每次请求apc是否检查文件修改,ini选项apc.stat控制这个设置,默认值为1,表示每次请求脚本时都减产脚本是否被更新,如果更新则自动重新编译和缓存编译后的内容,对性能有比例的影响,故这个设为0
3.通过ini选项apc.filters缓存更少的脚本
三、apc优点:
1.使用spinlocks(自旋)锁机制,能够达到最佳性能
2.apc提供apc.php,用于监控和管理apc缓存。(注:修改管理员名和密码)
3.apc默认通过mmap匿名映射创建共享内存,缓存对象都存放在这块大型的内存空间。由apc自行管理该共享内存
4.调整apc.shm_size、apc.num_files_hints、apc.user_entires_hint的值到最佳
5.php预定义常量,可以使用apc _define——constants()函数。不过apc开发者说pecl hidef性能更加,抛弃define,它是低效的
6.apc_store,对于系统设置等PHP变量,生命周期是整个应用(从httpd守护进程到httpd守护进程关闭),使用apc比memcache更好。(不需要经过网络传输协议)
7.apc不适用于通过函数apc_store()缓存频繁变更用户数据,会出现一些奇异现象。
例:
<?php /** *php apc示例 * by http://www. */ $constants = array('APC_FILE'=>'apc.php','AUTHOR'=>'tim'); apc_define_constants('memb',$constants ); apc_load_constants('memb'); //echo APC_FILE; //echo AUTHOR; if(!apc_fetch('time1')) apc_store('time1',time()); if(!apc_fetch('time2')) apc_store('time2',time(),2); //echo apc_fetch('time1'); //echo apc_fetch('time2'); class a{ public function b(){echo 'success';} } apc_store('obj',new a()); $a = apc_fetch('obj'); //$a-b(); $ret = apc_exists(array('foo', 'donotexist', 'bar')); //array(2) { ["foo"]=> bool(true) ["bar"]=> bool(true) } ?>
附,详细配置说明:
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
; 关于该指令目前尚无说明文档,参见:http://pecl.php.net/bugs/bug.php?id=8754
; 请保持为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字段值)。
代码如下:
<?php //sphinx简单例子 //参数筛选 //筛选cat_id=2 $cl->SetFilter("cat_id",array(2)); //仅在id为1、3、7的子论坛中搜索 $cl->SetFilter("forum_id",array(1,3,7)); //范围筛选 //筛选发布时间为今天,参数为int时间戳 $cl->SetFilterRange("starttime",123,124); //筛选价格 $cl->SetFilterRange("price",10.0,99.9); // 分组 //按照item_id分组,并且按照order desc排序 $cl->SetGroupBy("item_id",SPH_GROUP_ATTR,"order desc"); //排序模式 //按照price desc排序 $cl->SetSortMode(SPH_SORT_ATTR_DESC,"price"); 注意:会被SetGroupBy中的排序覆盖 // 匹配查询词中的任意一个 $cl->SetMatchMode ( SPH_MATCH_ANY ); SPH_MATCH_ALL, 匹配所有查询词(默认模式); SPH_MATCH_ANY, 匹配查询词中的任意一个; SPH_MATCH_PHRASE, 将整个查询看作一个词组,要求按顺序完整匹配; SPH_MATCH_BOOLEAN, 将查询看作一个布尔表达式 (参见 第 5.2 节 “布尔查询语法”); SPH_MATCH_EXTENDED, 将查询看作一个CoreSeek/Sphinx内部查询语言的表达式 (参见 第 5.3 节 “扩展查询语法”). 从版本Coreseek 3/Sphinx 0.9.9开始, 这个选项被选项SPH_MATCH_EXTENDED2代替,它提供了更多功能和更佳的性能。保留这个选项是为了与遗留的旧代码兼容——这样即使 Sphinx及其组件包括API升级的时候,旧的应用程序代码还能够继续工作。 SPH_MATCH_EXTENDED2, 使用第二版的“扩展匹配模式”对查询进行匹配. SPH_MATCH_FULLSCAN, 强制使用下文所述的“完整扫描”模式来对查询进行匹配。注意,在此模式下,所有的查询词都被忽略,尽管过滤器、过滤器范围以及分组仍然起作用,但任何文本匹配都不会发生. //从0开始查询,查询30条,返回结果最多为1000 $cl->setLimits(0,30,1000); // 从名称为index的sphinx索引查询“电影票” $cl->Query("电影票","index"); // 从名称为index的sphinx索引查询“电影票” $sp->SetGroupBy('item_id',SPH_GROUP_ATTR,'s_order desc'); $sp->SetFilter('city_id','1'); $sp->SetFilter('cat_id',array(1)); $sp->SetLimit(0,10,1000); $sp->AddQuery('电影票','index'); $sp->ResetFilters();//重置筛选条件 $sp->ResetGroupBy();//重置分组 $sp->SetGroupBy('item_id', SPH_GROUPBY_ATTR, 's_order desc'); $sp->setFilter('city_id', '2'); $sp->setFilter('cat_id', array(2)); $sp->setLimits(0, 20, 1000); $sp->AddQuery('温泉', 'index'); $sp->ResetFilters();// 重置筛选条件 $sp->ResetGroupBy();//重置分组 $results = $sp->RunQuries(); //by http://www. ?>
有关php sphinx的官方介绍,请参考文档:http://www./shouce/php5/book.sphinx.html。
批量查询(或多查询)使searchd能够进行可能的内部优化,并且无论在任何情况下都会减少网络连接和进程创建方面的开销。相对于单独的查询,批量查询不会引入任何额外的开销。因此当您的Web页运行几个不同的查询时,一定要考虑使用批量查询。
例如,多次运行同一个全文查询,但使用不同的排序或分组设置,这会使searchd仅运行一次开销昂贵的全文检索和相关度计算,然后在此基础上产生多个分组结果。
有时不仅需要简单地显示搜索结果,而且要显示一些与类别相关的计数信息,例如按制造商分组后的产品数目,此时批量查询会节约大量的开销。 若无批量查询,您会必须将这些本质上几乎相同的查询运行多次并取回相同的匹配项,最后产生不同的结果集。若使用批量查询,您只须将这些查询简单地组成一个 批量查询,Sphinx会在内部优化掉这些冗余的全文搜索。
AddQuery()在内部存储全部当前设置状态以及查询,您也可在后续的AddQuery()调用中改变设置。早先加入的查询不会被影响,实际上没有任何办法可以改变它们。
用上述代码,第一个查询会在“documents”索引上查询“hello world”并将结果按相关度排序,第二个查询会在“products”索引上查询“ipod”并将结果按价格排序,第三个查询在“books”索引上搜 索“harry potter”,结果仍按价格排序。注意,第二个SetSortMode()调用并不会影响第一个查询(因为它已经被添加了),但后面的两个查询都会受影响。
此外,在AddQuery()之前设置的任何过滤,都会被后续查询继续使用。因此,如果在第一个查询前使用SetFilter(),则通过 AddQuery()执行的第二个查询(以及随后的批量查询)都会应用同样的过滤,除非你先调用ResetFilters()来清除过滤规则。同时,你还 可以随时加入新的过滤规则。
AddQuery()并不修改当前状态。也就是说,已有的全部排序、过滤和分组设置都不会因这个调用而发生改变,因此后续的查询很容易地复用现有设置。
AddQuery()返回RunQueries()结果返回的数组中的一个下标。它是一个从0开始的递增整数,即,第一次调用返回0,第二次返回1,以此类推。这个方便的特性使你在需要这些下标的时候不用手工记录它们。
骆驼式命名法(又称驼峰命名法),正如它的名称CamelCase所表示的那样,是指混合使用大小写字母来构成变量和函数的名字。程序员们为了自己的代码能 更容易的在同行之间交流,所以多采取统一的可读性比较好的命名方式。例如:有些程序员喜欢全部小写,有些程序员喜欢用下划线,所以如果要写一个my name的变量,他们常用的写法会有myname、my_name、MyName或者myName。这样的命名规则不适合所有程序员阅读,而利用驼峰命名 法来表示,可以增加程序可读性。例如,下面是分别用骆驼式命名法和下划线法命名的同一个函数:
print_employee_paychecks();
第一个函数名使用了骆驼式命名法——函数名中的每一个逻辑断点都有一个大写字母来标记;第二个函数名使用了下划线法----函数名中的每一个逻辑断点都有一个下划线来标记。
骆驼式命名法近年来越来越流行了,在许多新的函数库和Microsoft Windows这样的环境中,它使用得相当多。另一方面,下划线法是c出现后开始流行起来的,在许多旧的程序和UNIX这样的环境中,它的使用非常普遍。
骆驼式命名法(Camel-Case)是电脑程式编写时的一套命名规则(惯例)。
骆驼式命名法就是当变量名或函式名是由一个或多个单字连结在一起,而构成的唯一识别字时,第一个单词以小写字母开始;第二个单词的首字母大写或每一个单词的首字母都采用大写字母,例如:myFirstName、myLastName,这样的变量名看上去就像骆驼峰一样此起彼伏,故得名。
骆驼式命名法(Camel-Case)一词来自 Perl 语言中普遍使用的大小写混合格式,而 Larry Wall 等人所著的畅销书《Programming Perl》(O'Reilly 出版)的封面图片正是一匹骆驼。
骆驼式命名法的命名规则可视为一种惯例,并无绝对与强制,为的是增加识别和可读性。
驼峰法(小驼峰法)
变量一般用小驼峰法标识。驼峰法的意思是:除第一个单词之外,其他单词首字母大写。譬如
变量myStudentCount第一个单词是全部小写,后面的单词首字母大写。
Pascal法(大驼峰法)
相比小驼峰法,大驼峰法把第一个单词的首字母也大写了。常用于类名,函数名,属性,命名空间。譬如