Performance 混凝土5厘米可扩展性和速度

我想从目前正在为大型内容网站使用混凝土的人们那里获得一些见解

与我一起工作的开发团队已经决定将其作为我们下一个项目的CMF

我对这个制度有些担心

可扩展性

在用户和数据量不断增长的同时，该系统能否继续平稳运行

速度

我遇到了一些非常慢的具体页面。这是我最大的担忧之一。页面加载速度如何？添加新页面是否会影响整个网站的速度？什么样的优化技术是可用的

前端灵活性

您是否仅限于在前端可以做什么

插件

使用插件插件与构建定制编码解决方案的优缺点。（例如速度、附加查询）

我正在尽最大努力确保我们开始开发的系统能够实现增长和稳定

---

免责声明：我是设计师和前端开发人员。我没有后端经验。

Concrete5如果使用正确，速度很快。就像任何东西一样，如果你滥用它，不维护它，那么它会变慢

我建议你读一下

前端的唯一限制是开发人员的能力。我是一个开发者，从来没有遇到过不可能的事情

有很多附加组件，创建自己的附加组件也很容易，尤其是使用

我在C5中运行了大量的站点，没有一个是慢的。所有这些都使用Varnish cache和Amazon的CloudFront，以充分利用我的硬件

你自己看看：

• （约2000页）

---

我无法置评，但也许第二个答案会帮助你做出决定
可伸缩性
在用户和数据量不断增长的同时，该系统能否继续平稳运行
对
速度
我遇到了一些非常慢的具体页面。这是我最大的担忧之一。页面加载速度如何？添加新页面是否会影响整个网站的速度？什么样的优化技术是可用的
系统具有块和整页缓存。如果您确保在带有APC的主机上运行它（可能另外还有带有PHP5.5的APCu），那么应该没有问题
前端灵活性
您是否仅限于在前端可以做什么
一点也不
插件
使用插件插件与构建定制编码解决方案的优缺点。（例如速度、附加查询）
如果你有一个问题需要一个在市场上可用的解决方案，你可以去解决它。通常他们都很好。 有时候，从市场上买一些东西并加以调整会更好，但concrete5可以让你自由书写所有东西
编辑： 我们现在在Concrete5上运行了另一个“大”页面，它比第一个页面更具动态性。它在一台服务器上每分钟提供超过500页的服务，峰值在你能想到的任何地方。 虽然您可以在页面缓存或Varnish/Cloud Flare上完全运行第一个较大的页面，但第二个页面是在线商店。尽管如此，Concrete5的灵活性允许您选择前进的道路。由于页面的外观不同，几乎每个页面的各个方面都不同，但我仍然觉得使用Concrete5是安全的，因为我可以改变我想要的每一种行为，而且不会因此而让我丧命。
Concrete5是以牺牲性能为代价为灵活性而设计的
一个非常简单的页面通常可以在一个请求中进行3000-10000次数据库查询，这是非常惊人的。
对于公共网站您需要启用全页缓存（或运行类似Varnish的HTML缓存），这样可以减少对大量查询的需求。但是，一些块和插件在整页缓存中遇到问题。从v5.7开始，我们的经验是它有缺陷，需要进行彻底的测试
在内部网和社区网站上（用户需要登录并检查权限），完整的HTML缓存并不总是有效的。在这些情况下，您可能需要审核您的自定义代码，并将查询函数的使用降至最低，而代之以您自己的自定义SQL查询
就连Concrete5的首席执行官也承认这一点：
没错，concrete5使用了相当多的数据库查询来呈现页面。同样，如果一个人从头开始设计一个应用程序来满足一个目的，那么在几个查询中解决大多数问题是很容易的。但是，正如您所知，concrete5在核心提供了巨大的灵活性。虽然我确信总会有机会清理查询和加载的对象数量，但当您拥有页面、块区域和块级权限时，您总是会大量访问数据库，每个权限都可能包括多个异常、定时发布等
我们的经验是，更重要的是关注实际使用，而不是抽象术语和基于直觉的规则。我们看到concrete5在企业级以两种截然不同的方式使用。有时，组织正在为其员工、经销商或合作伙伴建立外部网/内部网。这些通常需要复杂的权限和工作流程，这使得产品经理可以在不接触代码的情况下进行操作。这些站点，即使是在企业级，通常也提供数以万计的服务，并且可以在配置良好的web服务器上正常运行
其他时候，组织正在构建以前端为中心的信息站点。就交互性和复杂的权限而言，它们往往非常简单。其好处在于易于编辑。在这些情况下，我们所做的是在concrete5之前运行Varnish cache，这使站点比concrete5更快