自从 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 献给所有的开发者和用户，不拒分享，不畏前行，好的技术和经验只有分享，才会使整个环境改变和成长。
