PHP的优点之一是速度很快，但不能因为他的执行效率高而不对PHP的代码进行优化处理。在没有经过优化处理过的逻辑将会拖慢整个程序的执行效率。下面分析几个常见的问题:
使用error_reporting(0)函数来预防潜在的敏感信息显示给用户。理想的错误报告应该被完全禁用在php.ini文件里。可是如果你在用一个共享的虚拟主机，php.ini你不能修改，那么你最好添加error_reporting(0)函数，放在每个脚本文件的第一行（或用require_once()来加载）这能有效的保护敏感的SQL查询和路径在出错时不被显示。
为了提高产品的性能和效率，除了在MySQL和PHP方面做了优化处理外，Discuz! X2.5更重要的是在功能上进行了大量的调整。
member表优化 当一个数据表的数据量越来越大时，关于这个表的查询和更新操作就会变量越来越慢，为了提高数据库表的响应速度，应该时刻保持表数据的精简。那么如何既不影响正常功能又能保证表数据的精简？我们在十几个注册会员数从几十万到几百万不等的网站进行了一项非活跃用户数的统计，统计结果如下图：
统计结果显示非活跃用户数和活跃用户数的比例趋近于82规则，即非活跃用户数占大部分，因此只要我们将非活跃用户进行存档即可大大减少用户表的数据量，提高访问速度。
存档的标准是：
90天之内无访问且帖子数小于5，估算可优化60%以上用户。
程序处理过程：
a、用户在回访时将数据从存档表中转移到主表
b、单用户默认均不兼容处理
加为好友、打招呼、发短信将提示用户不存在或被冻结
用户空间、查看用户资料页可正常显示
c、多用户操作默认兼容处理
好友列表，帖子查看页可正常显示
d、后台用户管理时需要选表操作
post表的优化 在站点运营过程中，常遇到高楼贴的性能问题，比如 limit 187460, 20 。为了解决高楼贴可能出现的问题，Discuz! X2.5 做了如下调整：
1、增加position字段记录楼层，修改主键为：PRIMARY KEY (tid, `position`)联合主键，其中position 为auto_increment。
2、pid字段保留，仍然是auto_increment（单独的一个表），保持唯一，其值在一个单独的表中记录， 保留此字段的主要目的是可以让原程序的基本不用做修改。
使用方法：
SELECT * FROM pre_forum_post WHERE tid=424 AND position>=$start AND position<$end ORDER BY position;
3、抢楼贴和普通的盖楼贴机制统一。
4、删除和审核保留原来的机制，页面显示此楼层被删除或审核中。
点击数优化 在一个站点中，主题浏览量、文章查看数等数据实时更新时，需要频繁的写表操作，从而导致锁表问题。为了解决这一问题，Discuz! X2.5 做了如下调整：
1、增加forum_threadaddviews表，记录每一个TID的增量点击数。
2、查看帖子时，如果增量点击数到100，则使用进程锁将数据更新到thread表并更新增量点击数为0。
3、回贴时将增量点击数和回复数一起更新到thread表，并更新增量点击数为0。
4、执行计划任务：每天3点，5分钟一次，一次取500条数据更新到thread表， 并删除此500条数据，以减少forum_threadaddviews表的大小。
DIY模块更新数据优化 模块聚合数据的灵活性导致SQL语句的条件复杂且不使用索引，MYSQL对数据表的全表扫描，使网站的整体性能急剧下降。为了解决这一问题，Discuz! X2.5 做了如下调整：
1、在查询语句的WHERE条件中增加 id > max(id) - $maxnum。
2、最多扫描$maxnum行数据，产品后台可设置此值，最大是65535。
3、主题、文章、日志模块中添加此功能。
帖子点评和评分功能的优化 Discuz！X2.5 未优化前，查看帖子内容页时，需要分别到点评表和评分表中查询数据，必然产生含有 IN 操作的两条 SQL 查询，影响了站点性能。为了解决这一问题，Discuz! X2.5 做了如下调整：
1、增加forum_postcache表，记录每一个PID的点评列表和评分列表的结果。
2、查看帖子时生成缓存，点评和评分时删除缓存。
3、执行计划任务：每天删除前一天的数据，以减少forum_postcache表的大小。
内存级缓存优化 缓存层的引入是为了解决MYSQL自身对高并发处理的性能瓶颈，目前产品缓存层采用主流的Key-Value对形式，内存级的缓存产品很多，支持的内存优化接口有 Memcache、eAccelerator、Alternative PHP Cache(APC)、Xcache、Redis 五种，优化系统将会依据当前服务器环境依次选用接口，单服务器环境中推荐使用APC，多服务器环境中推荐使用Redis或Memcache。
数据层是以表为单位的类文件，所有表类都继承discuz_table基类，基类实现缓存操 作的相关函数；理论上所有的数据表均可以缓存，目前产品在六个压力大的数据表内置开启了缓存 机制：用户相关表、回帖、主题、主题和专辑关系、淘贴专辑、用户关注关系
用户相关表
数据 | 缓存KEY | 缓存时效 |
用户相关表 | UID | 表数据更新时缓存数据会同步更新 |
回帖 | TID | 缓存第一页的post数据,表数据更新时缓存数据会同步更新 |
主题 | TID | 表数据更新时缓存数据会同步更新(版块列表默认参数第一页时以 forumdisplay_FID 为缓存KEY,缓存时间内数据不更新) |
主题和专辑关系 | TID | 此TID的专辑ID集合,表数据更新时缓存数据会同步更新 |
淘贴专辑 | TID | 此TID的专辑集合,缓存时间内数据不更新 |
用户关注关系 | UID | 缓存时间内数据不更新 |
内存级缓存层实现细节 - /**
- * @var string 缓存主键名前缀,为空时表示此表不支持缓存
- */
- protected $_pre_cache_key;
- /**
- * @var string 缓存时间,以秒为单位，0表示永久或相关配置文件中的默认值
- */
- protected $_cache_ttl;
discuz_table 基类中缓存机制的方法
- //缓存一个变量到缓存中，如果 KEY已经在则会被覆盖为新值
- store_cache($id, $data, $cache_ttl = null, $pre_cache_key = null)
- //获取指定KEY的缓存数据
- fetch_cache($ids, $pre_cache_key = null)
- //清除指定KEY的缓存
- clear_cache($ids, $pre_cache_key = null)
- //更新一个已经存在的KEY,只更新修改的字段
- update_cache($id, $data, $cache_ttl = null, $pre_cache_key = null)
- //批量更新缓存，只更新已经存在KEY的指定修改的字段
- update_batch_cache($ids, $data, $cache_ttl = null, $pre_cache_key = null)
- //重置已经存在的KEY的值
- reset_cache($ids, $pre_cache_key = null)
- //累加缓存数据中某字段的值
- increase_cache($ids, $data, $cache_ttl = null, $pre_cache_key = null)
窥视卡
雷达卡
发表于 2013-12-24 00:10:41
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
发表于 2014-5-17 10:45:51
发表于 2014-5-28 07:16:22
发表于 2014-5-31 06:26:14
