易栈网-膘叔

这段代码不是挺复杂，其实如果你细看是可以看得到discuz中的authcode的影子的。如果你有兴趣，你可以看看：

发完这个贴子的时候突然发现。我好久没有写博客了。倒不是不坚持，而是发现我实在没有什么东西好写了。一直吃老本，还能写什么？

discuz的ajaxpost功能有点强大，但缺点也很明显，如果ajaxpost提交一个FORM，那么返回的时候只能显示showmessage的内容，而不会主动跳转，因此这里就有一个小技巧 了。。

比如默认submit按钮这样操作：onclick="ajaxpost('formid')";之类的，我们可以先这样。。
onclick="$('__formid').innerText='';ajaxpost('formid');checkPostResult();";
含义其实很简单，先把ajaxpost提示信息所在的div内容清空。然后提交。最后，根据返回值来判断。。

这个处理也很简单，为什么是用setInterval和clearInterval，主要是由于ajax是异步操作，如果不用setInterval方法 ，那么在ajaxpost结束的时候，其实提示信息还没有append到提示信息所在的ID里，所以用setInterval方法先延迟然后循环处理最后再结束提示。。。

clearInterval用的不太对，但短时间内想不到更好的。先这样临时解决喽。

登录phpoo.com的后台时，提醒我SS（supesite）7.5正式版提供下载了。正好我的SS也没有更新过程序，于是就直接更新了。。

在没有看程序的情况下，发现几乎没有什么大变化。

1、前台用户登录信息那一块，目前是自动收缩了。没什么感觉。。。我觉得是画蛇添足

2、用户的资料管理也提到前台来了。。cp.php?ac=profile，看这个链接就非常象uchome的操作，在uchome中，更改个人资料也是这个链接。。。

3、后台在信息管理那块多了两个：信息推送和点击器。信息推送分为：从uchome或BBS往 SS推送信息和从SS推送信息到uchome或BBS，点击器则更象一些大型网站的打分了。

这三个是比较明显的变化，其他的一些细节变化没有仔细看。。。

这是我的开发心得，但说白了，其实很简单。只要几个简单的步骤就可以了

1、到ucenter里创建一个新的应用，设定好你的路径，还有就是接收信息的文件，默认是uc.php，还有，是否同步登录，是否接受通知。

2、保存后，再编辑，你会发现最下面有一些define的字段，COPY出来，存为uc_config.php，放到你的项目里，留着被引用

3、到其他的dz程序里把uc.php COPY出来，进行简单的修改。根据第一步的设定，以确定你的最少action是什么。

1. 默认action中一定要有test，否则会通讯不成功
2. 如果开启通知，则一定要有updateapps，updateapps中有两个步骤：1是把所有的应用的缓存写入uc_client/data/cache/ucapps.php（好象文件名没记错）中；2是把当前APP_ID对应的配置重写为uc_config.php里
3. 如果开启同步登录，则需要有synlogin,synlogout两个action
4. 其他的就看你自己了，请对应手册，比如updatepwd，rename等操作。

4、部分uc_client函数返回是html代码，请echo出来看看是什么代码，如果是script的，请直接echo,否则无法与其他app同步。这个要切记切记。（为了这个，我测试了将近三天。可恨的是DZ代码中根本没有说明，只说返回HTML代码。）

其他就没有什么了。在你需要使用的时候调用一下uc_xxx的方法就行了。

这是来自imysql.cn的文章，作者是叶金荣，第一部分内容是3年前的了。可略作参考，估计7.0的数据库应该已经部分解决这个问题，第二部分是最新的。或许也能帮助你解决一些问题。

对于我来说是不用的啦。。我的论坛才几十个人。根本不需要用到这些功能。哇哈哈哈。
不过，我记得，如果是自己的服务器架设的论坛，DZ可以通过打开APC来进行缓存加速（好象是6.X版本中的功能。7.X没有研究过是不是还存在）

不说废话，看叶金荣先生的文章：

第一部分：

一. 前言
近日由于需要,对discuz论坛(简称dz)进行优化,当然了,只是涉及到数据库的优化.
先说一下服务器及dz的数据量,2 * Intel(R) Xeon(TM) CPU 2.40GHz, 4GB mem, SCISC硬盘.
MySQL 版本为 4.0.23. 数据表情况:
cdb_attachments 2万
cdb_members 10万
cdb_posts 68万
cdb_threads 7万
二. 缓存优化
在 my.cnf 中添加/修改以下选项:

#取消文件系统的外部锁
skip-locking
#不进行域名反解析,注意由此带来的权限/授权问题
skip-name-resolve
#索引缓存,根据内存大小而定,如果是独立的db服务器,可以设置高达80%的内存总量
key_buffer = 512M
#连接排队列表总数
back_log = 200
max_allowed_packet = 2M
#打开表缓存总数,可以避免频繁的打开数据表产生的开销
table_cache = 512
#每个线程排序所需的缓冲
sort_buffer_size = 4M
#每个线程读取索引所需的缓冲
read_buffer_size = 4M
#MyISAM表发生变化时重新排序所需的缓冲
myisam_sort_buffer_size = 64M
#缓存可重用的线程数
thread_cache = 128
#查询结果缓存
query_cache_size = 128M
#设置超时时间,能避免长连接
set-variable = wait_timeout=60
#最大并发线程数,cpu数量*2
thread_concurrency = 4
#记录慢查询,然后对慢查询一一优化
log-slow-queries = slow.log
long_query_time = 1
#关闭不需要的表类型,如果你需要,就不要加上这个
skip-bdb

以上参数根据各自服务器的配置差异进行调整,仅作为参考.
三. 索引优化
上面提到了,已经开启了慢查询,那么接下来就要对慢查询进行逐个优化了.
1. 搜索优化
搜索的查询SQL大致如下:

SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80;

用 EXPLAIN 分析的结果如下:

mysql>EXPLAIN  SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80; 
+-----------+------------+----------+--------------+-------------+-----------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref         | rows  | Extra
+-----------+------------+----------+--------------+-------------+-----------+-------------+
|  1 | SIMPLE      | t     | range | PRIMARY,fid   | fid  | 2       | NULL        | 66160 | Using where; 
Using temporary; Using filesort |
|  1 | SIMPLE      | p     | ref   | tid           | tid  | 3       | Forum.t.tid   |    10 | Using where
| +----+-------------+-------+-------+---------------+------+---------+-------------+-------+
---------

只用到了 t.fid 和 p.tid,而 p.author 则没有索引可用,总共需要扫描
66160*10 = 661600 次索引,够夸张吧 :(
再分析 cdb_threads 和 cdb_posts 的索引情况:

mysql>show index from cdb_posts; 
+-----------+------------+----------+--------------+-------------+-----------+----------
---+----------+--------+------+--+
| Table     | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | 
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+----
---------+-----------+-------------+----------+--------+------+--+
| cdb_posts |          0 | PRIMARY  |            1 | pid         | A         |      680114 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | fid      |            1 | fid         | A         |          10 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | tid      |            1 | tid         | A         |       68011 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | tid      |            2 | dateline    | A         |      680114 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | dateline |            1 | dateline    | A         |      680114 |     NULL | NULL   |
| BTREE      |         | 
+-----------+------------+----------+--------------+-------------+-----------+---

以及

mysql>show index from cdb_threads; 
+-----------+------------+----------+--------------+-------------+-----------+-------------+
----------+--------+------+-----+
| Table       | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part |
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+-----
--------+-----------+-------------+----------+--------+------+-----+
| cdb_threads |          0 | PRIMARY   |            1 | tid         | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            1 | topped      | A         |           4 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            2 | lastpost    | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            3 | fid         | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | replies   |            1 | replies     | A         |         233 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | dateline  |            1 | dateline    | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | fid       |            1 | fid         | A         |          10 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | enablehot |            1 | enablehot   | A         |           2 |     NULL | NULL   |
| BTREE      |         | +-------------+------------+-----------+--------------+-------------+------

看到索引 fid 和 enablehot 基数太小,看来该索引完全没必要,不过,对于fid基数较大的情况,则可能需要保留>该索引.
所做修改如下:

ALTER TABLE `cdb_threads` DROP INDEX `enablehot`, DROP INDEX `fid`, ADD INDEX (`fid`, `lastpost`);
ALTER TABLE `cdb_posts` DROP INDEX `fid`, ADD INDEX (`author`(10));
OPTIMIZE TABLE `cdb_posts`;
OPTIMIZE TABLE `cdb_threads`;

在这里, p.author 字段我设定的部分索引长度是 10, 是我经过分析后得出来的结果,不同的系统,这里的长度也不同,最好自己先取一下平均值,然后再适当调整.
现在,再来执行一次上面的慢查询,发现时间已经从 6s 变成 0.19s,提高了 30 倍.
这次先到这里,下次继续 ^_^

第二部分：

#skip-innodb
innodb_additional_mem_pool_size = 16M #一般16M也够了，可以适当调整下
innodb_buffer_pool_size = 6G #如果是专用db的话，一般是内存总量的80%
innodb_data_file_path = ibdata1:1024M:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 20
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 16M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 50
innodb_lock_wait_timeout = 120
innodb_file_per_table

mysql> alter table cdb_access engine = innodb;

膘叔认为：如果有自己的服务器，可以考虑做几件事情
1、如果有APC功能打开APC
2、如果没有APC，可以考虑把缓存目录指定为内存看看
3、GZIP关闭，少用rewrite等
4、在大负载的情况下，又只有一台服务器，考虑改程序，延迟插入或者其他的。。。（不太现实，哈哈）