Heim  >  Artikel  >  Backend-Entwicklung  >  (转)对帝国cms、dedecms、phpcms、discuz、phpwind、xiuno负荷测试总结

(转)对帝国cms、dedecms、phpcms、discuz、phpwind、xiuno负荷测试总结

WBOY
WBOYOriginal
2016-06-13 11:57:381463Durchsuche

(转)对帝国cms、dedecms、phpcms、discuz、phpwind、xiuno负载测试总结

担心被骂,本不想写这篇文章。犹豫良久,最终还是决定写。希望能够帮助到一些朋友,认识到数据库索引正确设计的重要性。

由于我比较懒,就简单用文字描述一下,就懒得切图片证明了,懂技术的朋友可以自己测试一下,可证实我的测试结果是否真实。不懂技术的朋友信不信也无妨。

测试程序:

CMS程序:帝国cms dedecms phpcms

论坛程序:discuz phpwind xiuno

负载测试结果:

xiuno > discuz > phpwind > phpcms >?(?帝国cms?? dedecms)

从数据库设计来看(个人观点):

xiuno >?(discuz?、 phpwind 、 phpcms)?>?(帝国cms 、 dedecms)

dedecms和帝国cms都是老牌的CMS了,从的数据库设计来看,不知是数据库设计者完全没有理解mysql索引的真谛,还是留一手以对高负载需求的用户收费改进?(希望不懂技术的朋友不要喷我,真正懂mysql索引的朋友可以自己看一下他们对索引的设计,虽然对于dedecms和帝国cms的作者来说,我只是一个晚辈,像您们这样有10多年开发经验的人,我比较尊敬,但我建议当前的dedecms和帝国cms数据库设计者还是再研究一下mysql索引吧,可以不相信我,但可以花点时间看看discuz 、phpwind的数据库设计吧,确实是比您们的好)。

如果有幸帝国cms作者能看到此文,希望您再重新设计帝国cms架构吧,毕竟这些年您一直在改进帝国cms的负载能力,光是通过分表技术提升,没有真正用到索引来优化,真的不行的,如果用对了索引,性能还会有更大的提升。

dedecms的创始人我算是和他认识,但现在dedecms却不是他的,比较遗憾,现在的dedecms这几年确实没多大变化,一直在打补丁,这样下去真是比较悲剧。

我的测试环境:

i3CPU 4G内存 1T硬盘 win7系统?? apache 2.2 + mysql 5.0(普通环境没有优化过)

测试方法:

导入100万至1亿?不等数据,进行简单的访问测试

我的导入方法:

根据各个程序的数据结构写出导入程序,

1.先写一个PHP程序,将数据写入 e:/insert1.sql 这个文件,

2.然后再通过 LOAD DATA local INFILE 'e:/insert1.sql' INTO TABLE `数据表名` character set 编码;?这种方式导入的,导入千W数据也就几分钟。

1、帝国cms

测试版本:EmpireCMS_7.0_SC_GBK (当前官方最新版)

先说说帝国cms,官方有一篇大数据测试贴(2千万数据、17.3GB数据库下帝国CMS超强生成速度?),当年我看到这篇测试贴时,也觉得负载非常强大,但我测试后,令我失望了。

安装默认测试数据(共33篇新闻测试数据),首页改为动态首页?第一次访问0.670127010345459 第二次访问0.07926607131958

我导入100W数据时,数据库大小3.6G,首页第一次访问182秒,第二次访问155秒,我不知道当时帝国cms作者测试时,是否有测试过动态访问首页的时间。包括从6.0版起,每次更新都有说提升性能,但为何会这样?

帝国CMS官方的测试帖,就是误导人,忽悠人。

问题1.测试数据并没有提到动态访问首页或是生成首页。也没有提到动态访问列表页,和生成列表页。

问题2.测试统计的时间,也只统计了连接数据库之后的执行时间,并没有加上连接数据库的时间,这样很容易误导很多人,拿这个时间和别人统计了连接数据库的时间比。这样就差别大了。

问题3.每篇新闻的内容很少也就几行字。同时内容页模板,也非常简单,生成出来的文件也非常小,只有3K。正常的文章,都是上10K至几十K。

问题4.同时因为phome_ecms_news表 id 为主键,读取内容时,都是走的索引,所以动态访问内容页,编辑内容,生成内容页很快,都是理所当然的。

问题5.测试时都是通过分表来测试的,在真实站长做网站,不可能一开始就把网站内容分表。所以这和真实做站情况完全不一样。

像官方这种测试贴,真是误导人,而且还挂了几年。对于不懂技术的人,就是一种误导,让普通用户盲目的崇拜。

2、dedecms

测试版本:DedeCMS V5.7 SP1_GBK正式版?(当前官方最新版)

织梦CMS在知度CMS中一直公认的负载性能最差的CMS,确实很差。

我导入100W数据时,数据库大小只有330M,首页访问已经需要70几秒-80几秒才能访问。

3、phpcms

测试版本:PHPCMS V9_GBK 正式版?(当前官方最新版)

PHPCMS现在是由新的团队重新开发,也是号称高负载。

我导入100W数据时,数据库大小3G,首页访问需要20几秒。

4、phpwind

测试版本:phpwind v9.0 UTF-8 正式版(当前官方最新版)

phpwind以前和discuz比,速度上有优势,现在据说是全新开发,新版确实做了很大的改变(以前一直是discuz追随者,和discuz设计差别不是很大),现在这一变化,应该值的赞扬,但现在速度上不如discuz了,以前网页底部显示执行时间都去掉了。

我导入1000W数据时,数据库大小13G,

首页第一次访问8秒,第二次访问0.70477390289307秒

帖子列表页(默认排序)0.2x-0.5x秒??但我采用按“最新发贴”排序时,花了182秒才显示出来(我看了数据库设计,因为只做了按“最后回复”的索引,“发帖时间”的排序都没做索引,所以才很慢)?

帖子内容页,没填充多少回帖也没具体测试

5、discuz

测试版本:Discuz_X2.5_SC_UTF8? Discuz_X3.0_SC_UTF8

dx3看来是dx2.5的加强版,从后台、前台设计看,都变化不大。数据库架构变化也不大。

我导入1000W数据时,数据库大小18G,

首页0.05-0.06秒,(也没太大测试价值,因为都没读到thread表)

帖子列表页(默认排序)0.07-0.09秒?但我采用按“发帖时间”排序时,花了181秒才显示出来(我看了数据库设计,因为只做了按“最后回复”的索引,“发帖时间”的排序都没做索引,所以才很慢)?

帖子内容页,(没填充多少回帖也没具体测试)

6、xiuno

测试版本:xiuno bbs 2.02 UTF8

我导入1000W数据时,数据库大小15G

首页0.03-0.05秒

帖子列表页0.03-0.05秒(回贴排序)??? 0.01-0.03秒(发帖排序)

帖子内容页0.03-0.05秒?(没填充多少回帖也没具体测试翻页)

我导入1亿数据时,数据库填充到215G

首页0.05-0.08秒

帖子列表页0.05-0.08秒(回贴排序)???? 0.03-0.05秒(发帖排序)

帖子内容页0.05-0.08秒?(没填充多少回帖也没具体测试翻页)

总结:

xiuno 虽然负载很高,但是功能上有很大的控制,去掉了很多可能影响到性能的功能,功能方面我觉得要是能有一个像wordpress这样的一个平台来弥补,那将会有非常大的优势。

discuz 虽然没做深入测试,不过已经可见负载上面还是有缺陷的,同时thread表设计为 tid mediumint(8) UNSIGNED 所以最大数值也就16777215,所以他的设计也并没有往更高考虑。

phpwind 这次的新版本的改变,证明了他们的决心,要和discuz走不同的路,也能看出来他们更注重用户体验方面。程序性能已经次之。

phpcms 性能是比以前提升了,但是用户体验我是感觉不太好。不过能够说明CMS性能方面不如BBS程序。因为排序方式多,而且同一个页面列表也比论坛的多,所以让CMS性能不如BBS。

帝国cms 虽然程序官方一直强调负载,但真还不如phpcms,光是通过分表提高负载,真不是一个好办法。我个人愚见,程序负载高不高,第一步应该是正确设计索引,索引都没设计对,就用分表来解决,而且还要站长手动设置,完全增加使用难度。

dedecms 虽然用户量非常大,但数据库设计真不好,不但索引没设计对,而且还没分表,而且也能看出dedecms并没有考虑做高负载,毕竟上百W级数据的网站很少。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn