给WordPress加了个每日谚语插件
11-23
discuz论坛在国内非常流行,用户众多。优秀的用户体验和超强的负载,也赢得了众多的好评。
但discuz毕竟是为中小型网站设计,很容易达到性能的瓶颈。在最近对discuz的改造和表结构的分析,做了以下的探讨,来提升论坛的性能。
第一步,当然就是分表。
技术实力不太强的用户(严重依赖mysql的用户),分表是最直接的做法(当然,有些功能会损失)。
分析一个运营两年的discuz数据库,库表大概是十几个G左右,posts数据表已经几个千万。
首先可以拆分的,就是post表了。根据情况,post表可以分10张,百张,规则可以哈希,也可以阶段自增(分表主键使用tid(帖子id))。分完表,可以看到一排post_**的表,每个表的数据量降到百万以下,速度就无太大影响。
第二个可以拆分的,是threads表,此表分表,可以水平分割方式水平的分割,可以根据论坛版块id进行分表,这样可以使每个表的数据量减小,但这样也损失了一个功能:全站标题检索。
通过以上两个表的改造论坛的承载能力能迅速见长。
底下会讨论高级优化改造得方法,且听下次分解。
好久不用PDO了,公司这边有的项目使用PDO,再熟悉一下,继续沿用之前的方法:
没用数据绑定和一些高级的功能,只是实现基础功能。
最近改了改UCenter Home,发现,这的确是个不错的产品,但不能算一个成熟的程序。
产品看法:
这个产品主要是服务一些个人站长和小型站点,功能模仿一些成熟的sns系统,模仿比较到位,而且功能上尽可能大的去完善,让管理员可以方便进行比较系统全面的管理。而从产品的设计体验上,也能适应中国大多数的用户。
所以,这个产品在国内算一套非常不错的sns建站系统。
编码方面:
要说代码,我相信阅读过代码的人一定很头疼,从discuz的bbs就这样。
代码只是面向过程,这个,在discuz方面,我估计是累积开发造成的,一个个版本升级,变化不能太大,如果变化真的太大,会失去一些开发者。另外,他自己升级也是个问题。
不过uch这个产品也开发成了这样。代码结构我倒挺喜欢,之前我写那个架子也是这样。优点:结构规范,适合多人协作。缺点,面向对象性,代码复用差。这个结构,我估计是公司某元老折腾的,然后有几个小弟进行模块开发。
为什么这么说,是有原因的,因为遍历整个代码,起码有两种以上的代码风格,而且人员之间沟通配合也造成了一些错误,虽然不是bug,但看得出来项目进行的仓促。不过这也是公司的一个战略措施,小戴同学总是及时放出产品来打压竞争对手。
再说负载,其实这个问题就不用说,从大量的垃圾sql语句就能看出,这个产品不能支持较大的负载。
再说最后一点,如果你想去优化改善,彻底改善,放弃吧。重写。
我看的只是uch2.0的预览版,估计正式版放出的时候,这些问题会有所改善。
增加了:跳转到第几页的功能
模板部分
其实我在做的时候又出现个问题,如果是url重写了,如何来做这个baseurl变量。问题解决方法是,把url当做模板,比如/blog/index/%d
这个算法写好多次了,虽然简单,但每次都得想一次,这里做个备份。
因为GD函数进行缩放,必须有宽和高,而在浏览器中,会自动按照比率调整宽高,所以两个函数稍有区别。
其实好久没用过FCKEeditor了,因为将近两年没写过CMS,今天突然人品大爆发,想起了这个问题。
fckeditor是一个非常棒的所见即所得在线编辑器,包括一些门户网站都在使用。fckeditor有个问题,就是上传图片默认为一个文件夹,当然这个问题早已经解决,我们可以用cookie或者session的方式给参数 $Config['UserFilesPath'] 就可以定制上传路径。而后在文章保存的过程中即可保存图片地址。
然后在使用过程中又出现一个问题,虽然我们知道图片在哪个文件夹,但我们却不能动态的去知道具体文件夹内有哪几个图片,预览是什么。而且,我们在写CMS的时候经常需要调用其中一张图片做封面,原来的机制显然无法去满足这些需求(当然你也可以查看编辑器内的源代码来查看图片地址,不过对于外行似乎有点困难)。
突然看到了discuz的附件机制,相出这么个损招:每张图片上传都给他存储在数据库中,打上guid(或者唯一的地址)进行标识,当我们保存的时候,图片会跟文章关联,在使用之前还可以用ajax动态调用预览,可谓一举两得。
文章保存后,图片进入数据库,另外还可以方便找出编辑遗留的垃圾,因为很多时候一个已经传了文章的草稿没有保存,而遗留很多的临时文件。
最近的fck版本好像升级了,配置文件放从根目录迁移了,不过fck代码非常规整,做这么个改造不是很难,就没写demo。
———————————————-
文章很冗余,骗稿费?