wellcms 架构设计思维,决定了承载量超大、性能超强、负载超高

燃烧的冰2020-03-10  152

自从 wellcms 2.0 正式版发布以来,受到很多用户和同行的关注。有同行体验测试、研究 wellcms 不明白的地方,给我发邮件咨询相关问题,在这里我统一回答一次,免得总是做重复回答。


wellcms 架构设计思维,决定了承载量超大、性能超强、负载超高


首先搞明白承载、性能和负载是三个不同的事情,尤其很多人会把负载看成性能。


wellcms数据承载量:不用怎么多解释,看字面也能明白。


wellcms性能:是在指定的环境下,系统执行和响应时间的最好情况。这个也好明白,其实就是你干事的时间长短,有的事时间长比较好。但查询数据时间越短越好,尤其是在海量数据下,别人千分之三秒出数据,你那里3秒页面还是空白,这还谈什么用户体验呢?


那么,很多人怀疑 wellcms 的大数据量承载下的高性能是噱头。我可以准确告诉你,这就是噱头,因为wellcms能做到,不信自己去百度,看看有多少站点采集了几百万数据,缓存都没开依然0.00x秒打开每个页面。


不是我喷你,你可以用怀疑的眼光看待事物,但不要用有限的知识和经验,批判别人能做到的事情,那会限制你成长。技术的精进、经验的淬炼,必须在实践中遇到问题后去反思、去总结、去学习,才会突破瓶颈、快速成长。


有人说性能跟某某框架有关,如果你这样认为,我不进行评价。我只能说当你的思维没被框住的话,使用什么框架都可以写出性能高的系统。被限制的是思维,不是技术本身。


wellcms 为什么承载量大,性能还如此好?


第一、wellcms 不在数据库做任何预算,注意是任何运算都不做,只把MYSQL当做储存库使用,不把数据库当成“财务会计”使用。


wellcms 数据表的设计,字段类型的使用,索引的使用,SQL语句的写法,wellcms 都有约束,关于这方面的约束请查看使用手册,插件说明,我不在赘述。

地址直达 http://www.wellcms.cn/read-71.html


其他程序承载量上不来,性能高不了,这里的问题最大,注意:是最大问题就在数据表的设计,字段的使用,索引的创建。


wellcms 做了什么?

1.主题数据与内容数据拆分单独的表,因为绝大部分操作,都是对主题的操作;

2.对于主题数据表只有一个主键索引,没有其他,所有其他索引一律分离到附表。


那么 wellcms 单表承载是多少呢?你高兴的话,单表42亿也可以,wellcms 性能和负载依然会很牛,不信你自己试试。但是我建议,单表到1亿的时候进行分区或分库,不要分表,不要分表,不要分表。


分区和分库是为了使性能更好,其次以后管理也方便,不然,你对几十亿数据的表进行管理的时候会很酸爽的。


第二、wellcms 所有操作会向上一层反馈数据,但不做间接反馈数据,其他程序性能上不来,这里的问题也比较大。因为,很多经验不丰富的开发者根本不做反馈数据处理;


第三、业务逻辑的设计,尽量简单,因为业务场景越简单,表现越出色。有些开发者,自己都没理清业务逻辑,又或者理清了逻辑,根本没有进行逻辑优化,就开始闷着头撸代码了。其实你这样撸代码,到时最受不了的是DBA,管他呢,不累死丫的哪行,拿那么高的工资,天天写那么长的SQL语句装X。


对于后端最好的做法,就是只做数据处理,其他全部甩锅前端。


第四、代码书写,尽量使用内置函数,不要自己写一些即啰嗦问题又多的函数;

1.所有数据的筛选尽量 foreach 一次完成;

2.尽量使用三目运算;

3.尽量避免筛选大数组;

4.在保证数据安全的情况下,压力能分摊到客户端,就别在服务端。也就是 JS 能完成的,就别用 php 完成。


wellcms 负载:是指数据在超负荷环境中运行,程序响应同时间访问的承载量,强调的是达到的峰值指标。

压测的目的,是为了测试程序在及其恶劣的环境下,服务器资源处于极限状态下并长时间运行,后端是否运行正常,系统是否稳定。你可以理解为服务器资源、SQL查询次数和响应时间、前端页面大小都与之相关。


服务器是运维的事;页面代码越少越好,这个是前端的事;而SQL查询次数和响应时间,这个跟程序有很大关系了,一个页面5条SQL响应完全部数据,跟100条SQL查询才响应完全部数据的差别就很大了。遇到高并发的时候,要么服务器死,要么网站死,反正都活不成。你一个页面搞那么多SQL语句,而且很多是重复查询同一个表,DBA爆你菊花的心都有。


这就好比,地铁站,一节车厢载50人,出口一次性出10个人是正常没有问题的情况下。但高峰期时,一节车厢突然暴涨到100人拥挤,150人挤成照片,出口由原来的出10变成20个、30个人的时候,那么问题就出来了。


做网站也是一样,刚开始的时候没什么访问量,怎么造,都不无所谓。但是用户量越来越高,数据量越来越大,访问量越来越高,问题也就越来越多。其实,一开始选择使用 wellcms 是最正确的做法,因为,wellcms 已经提前为你处理好了这些问题,最低配环境下,wellcms 的性能和承载都出奇的高。


理论压测单表 10亿 数据,压测环境1H/2G/SSD/OPcache/Yac,内容页ab压测200并发,10000次请求,failed:0(230并发时才开始出现错误),RPS:1046,TPR:95.49,TPR:0.951。理论上每天承载1046 * 86400 = 90,374,400次请求,意味着 WellCMS 在低配环境下,每天承载着9000万次的页面访问并且无错。即使去掉峰值,每天轻松胜任千万次请求。


可以粗略的理解这2个含义,假设让你在操场跑圈:

压力测试:就是给你施加外部压力,让你围着操场一直快速奔跑,不让你休息,不让你喝水,不给你饭吃,看看你最大限度跑多少圈,什么时候倒地报废?

负载测试:在指定单位时间内,逐步增加你的跑步圈数。原来一分钟你能跑几圈,2分钟能跑几圈,不同单位时间内你跑圈的速度和质量。


压力测试和负载测试分别能帮我们找到程序的抗压能力和工作能力,也能帮我们评估一个系统的性能瓶颈和质量。


一次把事情做对,这篇内容,即献给同行开发者,也献给 wellcms 的插件开发者,因为 wellcms 的应用中心近期准备上线了, wellcms 希望传承技术和经验的情况下,也传承经典的作品。


wellcms 献给所有的开发者和用户,不拒分享,不畏前行,好的技术和经验只有分享,才会使整个环境改变和成长。


最新回复(2)