㈠ php开发中如何提高系统的稳定性和可靠性
PHP 应用的高性优化,很多时候我们把业务代码做一些优化,反而是简单又高效的。
业务的异步解耦,比如,我们把耗时的多个分表数据的排行榜,通过其他服务做分布统计,然后再综合,最终输出到redis list中,那我们前端 PHP 在调用数据的时候,就不用实时计算了。
缓存的多级处理,业务复杂以后,经常看到一份相同的数据读取 N 次,尽管是有缓存服务器,但是读取的时候也会有网络 I/O 的开销,考虑到我们 PHP 一般使用场景下都是单进程,使用频率高的,则应该优先使用进程内缓存。然后再本地缓存,然后再到网络缓存。
单例的运用,不要小看了对象的构造,很多时候我们在同一进程中,会发现同时构造了 N 多相同的对象。每一次的初始化都是一块内存的开辟和 CPU 的消耗。
高性能,一个就是运行环境的优化,另一个是代码本身的优化。
运行环境的优化,覆盖面也很广,包括系统层面的内核,文件系统类型,数据库及缓存服务本身的性能优化,再到PHP解释器的性能优化等等,PHP不同运行方式的差异(比如Apache模块,还有PHP-FPM等等)。
代码优化方面,我觉得可维护性和代码可读性的重要性大于高性能。代码优化可以借助profiling工具来分析,找到真实访问条件下,处理瓶颈在哪里,再去做针对性的优化。当然自己在初次设计和实现的时候,就需要做一定的整体考虑,例如怎么设计能够减少数据库的查询次数,如何减少重复的操作,了解同一问题的多种解决办法哪一种效率更高(包括算法上的差异,以及PHP的不同方式导致的差异等等),如何设计缓存来提高缓存命中率等等。有一些设计需要在体验和效率上做个权衡。
保证稳定性,同样也分运行环境和代码本身。前者要对线上服务做完整的监控,这个有很多完善和强大的开源工具可以使用,保障基础环境是稳定可控的,并且能够及时发现问题,进行修复。至于代码,除了尽量做完整的测试,开发的时候就需要考虑可能的问题。另外针对PHP,开发环境可以把error_reporting完全打开。还有需要知道常见的安全问题(XSS,SQL注入,CSRF,越权等),毕竟安全问题也是稳定的一部分。
㈡ php+mysql 如何优化千万级数据模糊查询加快
关于mysql处理百万级以上的数据时如何提高其查询速度的方法
最近一段时间由于工作需要,开始关注针对Mysql数据库的select查询语句的相关优化方法。
由于在参与的实际项目中发现当mysql表的数据量达到百万级时,普通SQL查询效率呈直线下降,而且如果where中的查询条件较多时,其查询速度简直无法容忍。曾经测试对一个包含400多万条记录(有索引)的表执行一条条件查询,其查询时间竟然高达40几秒,相信这么高的查询延时,任何用户都会抓狂。因此如何提高sql语句查询效率,显得十分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法:
1、应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
2、对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。
3、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
4、尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10
union all
select id from t where num=20
5、下面的查询也将导致全表扫描:(不能前置百分号)
select id from t where name like ‘%c%’
若要提高效率,可以考虑全文检索。
6、in 和 not in 也要慎用,否则会导致全表扫描,如:
select id from t where num in(1,2,3)
对于连续的数值,能用 between 就不要用 in 了:
select id from t where num between 1 and 3
7、如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然 而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
select id from t where num=@num
可以改为强制查询使用索引:
select id from t with(index(索引名)) where num=@num
8、应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num/2=100
应改为:
select id from t where num=100*2
9、应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where substring(name,1,3)=’abc’–name以abc开头的id
select id from t where datediff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id
应改为:
select id from t where name like ‘abc%’
select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′
10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
11、在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使 用,并且应尽可能的让字段顺序与索引顺序相一致。
12、不要写一些没有意义的查询,如需要生成一个空表结构:
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:
create table #t(…)
13、很多时候用 exists 代替 in 是一个好的选择:
select num from a where num in(select num from b)
用下面的语句替换:
select num from a where exists(select 1 from b where num=a.num)
14、并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段 sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。
15、索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有 必要。
16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。
17、尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
18、尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。
19、任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。
20、尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
21、避免频繁创建和删除临时表,以减少系统表资源的消耗。
22、临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使 用导出表。
23、在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。
24、如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。
25、尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。
26、使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。
27、与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时 间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29、尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。
30、尽量避免大事务操作,提高系统并发能力。
㈢ 升级php7.3 linux服务器cpu 突然很高
1、通过宝塔面板安装的建站环境是LNMP,使用的Nginx 1.16.1、MySQL 5.5.62、PHP-7.0。2、优化PHP7.0设置。先进入到PHP7.0管理页面。首先先安装一个opcache缓冲器,用于加速PHP脚本,其他的就都按默认的来吧,毕竟安装的扩展太多容易影响性能。修改max_execution_time时间为20.性能调整。这里可以根据自己服务器配置进行设置,宝塔面板比较人性化,会根据你的服务器配置设置推荐方案。可以根据自己服务器内存大小进行计算,一般一个php-fpm进程占用内存30M左右,以1024MB内存1G内存)来计算,大概可以设置34个并发。使用的就是1核1G内存配置的服务器,安装宝塔面板后推荐的是40并发,用不到那么高的并发,所以设置了20并发的方案,并把max_spare_servers数字调整成了14。
㈣ 如何对低硬件配置的中小型php网站进行性能优化
本人对php不熟悉,现在采用PHP的magento开源项目来做,在尽量少代码修改的情况下让页面加载快些(期望日IP少于2,000,PV少于50,000,首页打开3s以内)。网站是运行在Digital ocean的VPS(1GB 内存,30GB SSD硬盘)上的,不能做负载均衡。
这个站的图片比较多,也比较大,但总体数据量在10GB以下。在chrome下监控了打开速度,发现首页文件等待时间达到了5s,而接收时间为几百毫秒。另外一些静态文件(JS,CSS很大,并且都在head内)也block住了其他页面元素的下载和页面渲染。所以需要对页面和服务器同时进行优化。
我的想法是从以下几个方面来做:
1.首先从架构上使用lanmp(偏向这个)或者lamp。
打算使用网上的一键安装包,不太清楚这几个之间最佳的版本组合是什么样的(都用最新版本?)? 是自己单独编译还是一键安装好?
2.服务端优化,主要使用缓存手段
1)Zend Optimizer优化PHP
2)APC、eaccelerator或者XCache对PHP缓存以及最新出来的Opcache。哪个比较好?
3)Varnish配合Nginx进行缓存静态资源缓存。相对于squid,哪个比较好?
4)memcached进行数据库缓存
1-4项同时使用不知道会不会有没有冲突?或者有没有更好的方案。因为不想对代码进行大改,所以服务端缓存最佳实践这块请重点给出意见。
3. 使用CDN加速静态资源
4. 优化静态资源,使用minify来合并压缩CSS,JS这些静态资源
5. 启用gzip
6. 对图片和JS等静态资源增加Expires头,这条应该算页面优化吧,放到后面来。
参考了一些资料后发现优化方法有很多,用的太多方法(特别是缓存手段)隐患越大,有没有优化的最佳策略或者方法论(而不仅仅从工具上)?
㈤ php有哪些优化技巧
优化的点有很多,看具体使用环境:
1、 用单引号代替双引号来包含字符串,这样做会更快一些。因为 PHP 会在双引号包围的 字符串中搜寻变量,单引号则不会,注意:只有 echo 能这么做,它是一种可以把多个字符 串当作参数的“函数”(译注:PHP 手册中说 echo 是语言结构,不是真正的函数,故把函数 加上了双引号)。
2、如果能将类的方法定义成 static,就尽量定义成 static,它的速度会提升将近 4 倍。
3、$row['id'] 的速度是$row[id]的 7 倍。
4、echo 比 print 快,并且使用 echo 的多重参数(译注:指用逗号而不是句点)代替字符串 连接,比如 echo $str1,$str2。
5、在执行 for 循环之前确定最大循环数,不要每循环一次都计算最大值,最好运用 foreach 代替。
6、注销那些不用的变量尤其是大数组,以便释放内存。
7、尽量避免使用__get,__set,__autoload。
8、require_once()代价昂贵。
9、include 文件时尽量使用绝对路径,因为它避免了 PHP 去 include_path 里查找文件的速 度,解析操作系统路径所需的时间会更少。
10、如果你想知道脚本开始执行(译注:即服务器端收到客户端请求)的时刻,使用 $_SERVER['REQUEST_TIME'] 要好于 time()
11、函数代替正则表达式完成相同功能。
12、str_replace 函数比 preg_replace 函数快,但 strtr 函数的效率是 str_replace 函数的四倍。
13、如果一个字符串替换函数,可接受数组或字符作为参数,并且参数长度不太长,那么 可以考虑额外写一段替换代码, 使得每次传递参数是一个字符, 而不是只写一行代码接受数 组作为查询和替换的参数。
14、使用选择分支语句(译注:即 switch case)好于使用多个 if,else if 语句。
15、用@屏蔽错误消息的做法非常低效,极其低效。
16、打开 apache 的 mod_deflate 模块,可以提高网页的浏览速度。
17、数据库连接当使用完毕时应关掉,不要用长连接。
18、错误消息代价昂贵。
19、在方法中递增局部变量,速度是最快的。几乎与在函数中调用局部变量的速度相当。
20、递增一个全局变量要比递增一个局部变量慢 2 倍。
21、递增一个对象属性(如:$this->prop++)要比递增一个局部变量慢 3 倍。
22、递增一个未预定义的局部变量要比递增一个预定义的局部变量慢 9 至 10 倍。
23、仅定义一个局部变量而没在函数中调用它,同样会减慢速度(其程度相当于递增一个局 部变量)。PHP 大概会检查看是否存在全局变量。
24、方法调用看来与类中定义的方法的数量无关,因为我(在测试方法之前和之后都)添加了 10 个方法,但性能上没有变化。
25、派生类中的方法运行起来要快于在基类中定义的同样的方法。
26、调用带有一个参数的空函数,其花费的时间相当于执行 7 至 8 次的局部变量递增操作。 类似的方法调用所花费的时间接近于 15 次的局部变量递增操作。
27、Apache 解析一个 PHP 脚本的时间要比解析一个静态 HTML 页面慢 2 至 10 倍。尽量 多用静态 HTML 页面,少用脚本。
28、除非脚本可以缓存,否则每次调用时都会重新编译一次。引入一套 PHP 缓存机制通常 可以提升 25%至 100%的性能,以免除编译开销。
29、尽量做缓存,可使用 memcached。memcached 是一款高性能的内存对象缓存系统, 可用来加速动态 Web 应用程序,减轻数据库负载。对运算码 (OP code)的缓存很有用,使 得脚本不必为每个请求做重新编译。
30、 当操作字符串并需要检验其长度是否满足某种要求时, 你想当然地会使用 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()作为一种语言结构,意味着它 的执行不需要函数查找和字母小写化。 也就是说, 实际上在检验字符串长度的顶层代码中你 没有花太多开销。
31、当执行变量$i 的递增或递减时,$i++会比++$i 慢一些。这种差异是 PHP 特有的,并不 适用于其他语言, 所以请不要修改你的 C 或 Java 代码并指望它们能立即变快, 没用的。 ++$i 更快是因为它只需要 3 条指令(opcodes),$i++则需要 4 条指令。后置递增实际上会产生一 个临时变量,这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的 一种,正如 Zend 的 PHP 优化器所作的那样。牢记这个优化处理不失为一个好主意,因为 并不是所有的指令优化器都会做同样的优化处理, 并且存在大量没有装配指令优化器的互联 网服务提供商(ISPs)和服务器。
32、并不是事必面向对象(OOP),面向对象往往开销很大,每个方法和对象调用都会消耗很 多内存。
33、并非要用类实现所有的数据结构,数组也很有用。
34、不要把方法细分得过多,仔细想想你真正打算重用的是哪些代码?
35、当你需要时,你总能把代码分解成方法。
36、尽量采用大量的 PHP 内置函数。
37、如果在代码中存在大量耗时的函数,你可以考虑用 C 扩展的方式实现它们。
38、 评估检验(profile)你的代码。 检验器会告诉你, 代码的哪些部分消耗了多少时间。 Xdebug 调试器包含了检验程序,评估检验总体上可以显示出代码的瓶颈。
39、mod_zip 可作为 Apache 模块,用来即时压缩你的数据,并可让数据传输量降低 80%。
40、在可以用 file_get_contents 替代 file、fopen、feof、fgets 等系列方法的情况下,尽量 用 file_get_contents,因为他的效率高得多!但是要注意 file_get_contents 在打开一个 URL 文件时候的 PHP 版本问题;
41、尽量的少进行文件操作,虽然 PHP 的文件操作效率也不低的;
42、优化 Select SQL 语句,在可能的情况下尽量少的进行 Insert、Update 操作(在 update 上,我被恶批过);
43、尽可能的使用 PHP 内部函数(但是我却为了找个 PHP 里面不存在的函数,浪费了本可 以写出一个自定义函数的时间,经验问题啊!);
44、 循环内部不要声明变量, 尤其是大变量: 对象(这好像不只是 PHP 里面要注意的问题吧?);
45、多维数组尽量不要循环嵌套赋值;
46、在可以用 PHP 内部字符串操作函数的情况下,不要用正则表达式;
47、foreach 效率更高,尽量用 foreach 代替 while 和 for 循环;
48、用单引号替代双引号引用字符串;
49、“用 i+=1 代替 i=i+1。符合 c/c++的习惯,效率还高”
50、对 global 变量,应该用完就 unset()掉;